
Towards Crystal 1.0 - chenzhekl
https://crystal-lang.org/2020/03/03/towards-crystal-1.0.html
======
jwiley
I tried Crystal for a small hobby project a few months back, and was generally
impressed by the stability, ease of use and documentation. I found the type-
system very straight forward, and with less mental overhead than Rust,
obviously with all the design tradeoffs that entails. For the use-cases I'm
interested in, Crystal has a little ways to go in terms of mindshare and
ecosystem support, but it's a fun language to learn and try.

------
abhorrence
I generally like Crystal. However I think there’s a some unfortunate choices
that make it hard to use. I’d really love to see them addressed (or planned
for) before 1.0:

\- global inference is more trouble than its worth. some way to opt sections
of code out of global inference in exchange for faster compile times and
better type error messages would be wonderful

\- conflicting/duplicate C bindings in libraries aren’t easy (or even possible
sometimes) to reconcile

\- a lot of standard library interfaces to system stuff (e.g. sockets) are
hard to extend for additional uses. there’s a number of reasons for this, but
among them: enums wrapping simple integer based enums, but not actually
covering all the values.

\- parser is hard to reuse outside of the compiler itself, which is an
impediment to making neat tools.

\- some strange choices around co/contra-variance when dealing with arrays

~~~
chrisseaton
> global inference

I think this is long-gone isn't it? It's local now.

> parser is hard to reuse outside of the compiler itself

A problem we repeat again and again!

~~~
abhorrence
I think it's maybe less global than it was previously (and in a way that helps
pave the way for improving compile times), but there's still a lot of ways to
cause spooky type errors at a distance due to the assignment type inference
rule.

    
    
      module Example
        def self.some_method
          "string"
        end
        
        class Foo
          getter :var1
        
          def initialize
            @var1 = SomeUtilities.something
          end
        end
    
        module SomeUtilities
          def self.something
            Example.some_method
          end
    
          def self.do_something_with_string(input : String)
            puts input
          end
        end
      end
       
      Example::SomeUtilities.do_something_with_string(Example::Foo.new)
    

If you change Example.some_method to return :symbol, you now get a type error
on the final line.

~~~
yxhuvud
I like that behaviour. Normally you don't get to pay the overhead of having to
spell it out but it is a nice tool to have, being able to gradually add type
information to fence in errors.

------
abhijat
Would any crystal users care to comment on how the editor story is now with
crystal?

I tried it a few months ago and scry was not giving me any autocomplete in vs
code.

~~~
nobleach
Editor story is a bit rough still. I'm using scry (the Crystal Language
Server) with coc-nvim. It seems to be a little bit smarter than simple "words
in buffer" completion, but not much. Sometimes it just quits and I haven't
investigated why. Currently I'm just writing spec tests and simple data
structures/algorithms. (the typical thing I do when learning a language) I did
start a Lucky project this past weekend to see what that's all about. If I get
more into it, I'll probably break down and figure out how to fix
autocompletion/go-to-definition/show-references/etc.

------
joelbluminator
Any heavy users? As a Ruby/Rails dev, do I have something to gain from
learning this?

~~~
WJW
Depends on if you have any cpu-bound endpoints. At my previous employer we
moved a very intensive check (high dimensional vector nearest neighbor search)
into a separate Crystal microservice and even with RPC overhead it was easily
100x faster than the ruby version. This with code that any Ruby dev could
instantly read, unlike if we would have gone for a C extension. That said,
Ruby still has a massive lead in available gems, so don't uninstall Rails yet.

~~~
suzuki
In my experiment, the Crystal version ([https://github.com/nukata/little-
scheme-in-crystal](https://github.com/nukata/little-scheme-in-crystal)) was
38x faster than the Ruby version ([https://github.com/nukata/little-scheme-in-
ruby](https://github.com/nukata/little-scheme-in-ruby)) and comparable to the
Java version ([https://github.com/nukata/little-scheme-in-
java](https://github.com/nukata/little-scheme-in-java)). Indeed, it is in the
fastest group. See [https://github.com/nukata/little-
scheme#performance](https://github.com/nukata/little-scheme#performance)

------
Naac
As another person mentioned, the main thing keeping me from Crystal is proper
editor support, and more specifically proper debugger support.

I really like the experience working in python in pycharm, mainly for the
integrated debugger.

It would be great to see an open source editor for Crystal with proper
Debugger support and code reference lookup.

~~~
ejstembler
Though I have a long history with IDEs I feel just as comfortable with the
console, or the lighter-weight, electron-based IDEs.

For the last couple of years I've lived pretty much exclusive in the
Ruby/RubyMine, Python/PyCharm, Scala/IntelliJ worlds.

However, I recently finished a medium-sized Crystral project only using
VSCode. For debugging, I wrote unit tests and kept Sentry running. The
compiler pretty much catches everything else. The combination worked out very
well.

------
faitswulff
I don't yet use Crystal, but it's kind of painful that Windows support is in
the "What can wait? - after 1.0" section. Cross-platform support is one of the
reasons I've been diving into Rust.

However "we integrated a CI for Windows to ensure we continue moving steadily
forward" sounds like a good compromise for limited resources.

~~~
moonchild
I find it a little sad that windows support is considered essential (and its
lack is a dealbreaker), but linux support is not, even though developers
predominantly use macos and linux.

~~~
AlchemistCamp
Why do you believe more devs are on mac than windows? What country are you in?

------
ejstembler
I wrote my blog using Crystal 0.33 (plus kemal and bulma) and it's great!
[https://ejstembler.com](https://ejstembler.com)

------
petre
Is it just my browser or is scrolling broken on mobile on the Crystal site? It
only breaks after 10s or so. Weird.

------
dzonga
how does Crystal compare to Nim ?

~~~
ejstembler
I actually started writing my blog in Crystal, took a little break, and
started writing it in Nim. I really like Nim a lot. Some of the code came out
more concise in Nim. I like how Nim handles nils better. Options instead of
temp var shadowing. I would've finished my blog in Nim had I not ran into an
issue with embedded-style templates. Think eRb in Ruby. Crystal handles this
by compiling and embedded. Nim doesn't support that. I had to resort to
something like Mustache which I didn't want to use. Ultimately, I went back to
Crystal and finished it.

~~~
nimmer
Nim string templating is very powerful. What is your unmet need, precisely?

~~~
ejstembler
I couldn't get embedded templating to work for nim. Something similar to
Ruby's ERB: [https://ruby-
doc.org/stdlib-2.7.0/libdoc/erb/rdoc/ERB.html](https://ruby-
doc.org/stdlib-2.7.0/libdoc/erb/rdoc/ERB.html). Or Crystal's ECR:
[https://crystal-lang.org/api/0.21.1/ECR.html](https://crystal-
lang.org/api/0.21.1/ECR.html)

