asterite's comments

Those functional languages don't have function overloading or named arguments. The type inference in Crystal works very differently. The type of a method can only be computed from explicit calls to it. In those functional languages the type can be computed independent of a call because it's trivial to do so if a function name always refers to a single entity.

"Fast as C" should maybe be changed to something else. Crystal can bind directly to C functions and libraries without any overhead, plus you have pointers and other stuff. So you could really write code that runs as fast as C if you program like in C, but with Crystal syntax. That's where the tagline comes from. But of with course normal usage of the language, with its heap-allocated stuff, garbage collector and usual stuff (like Array#map, which does allocate a new array), you won't get performance like C, but it will be acceptable, and usually faster than dynamic/interpreted languages.

Oh, release builds do take longer.

My point of view is that while developing you don't need the `--release` flag, so you can get a more or less fluent experience. The few times where you need to release an app it takes longer, but for me that's acceptable.

That's about speed (though I think Truffle/Graal make an app consume more memory). Crystal is type-safe, and no optimizing VM can do that for Ruby.

Not that type-safety is a killer feature, but that's just one difference.

The compiler takes about 30 seconds or a bit more to compile, and it has around 50000 lines of code. Do you have the few hundred lines that took you 30+s to compile?

You could basically say the same about any language. Just switch the descriptions. For example:

C#: verbose, magical dependency injection, Microsoft, etc.

Ruby: slow

Go: ugly syntax, verbose, if err != nil, etc.

If a language works for you I see no reason not to use it :-)

I wouldn't commit to any specific date. It's not something you can timebox.

Here are the reasons for 'end': https://github.com/crystal-lang/crystal/wiki/FAQ#why-isnt-th...

Yes, it will be available before 1.0. It's on the roadmap.

Yes, this is what Crystal 1.0 will look like. Parallelism is on the roadmap.

We do, and we will. We are working on it :-)

Thank you! I didn't know that easy way to reply.

The compiler does some incremental compilation for the generated object files, so compile times are kept relatively small. Other than that, I don't think it makes a big difference for a developer except saving compile times. On the other hand, in this way you can't have a compiled library conflict so you have to "clean and rebuild" when this happens.

For example in Ruby there's no such thing as pre-compiling a gem, and every time you run an app the whole app is "analyzed" (parsed and converted to VM instructions), and so you can think in Crystal it's the same (except that it's compiled to native code)

I can't seem to reply to your reply to this, but the error message has nothing to do with where a class is defined.

You can't compile a part of your application in crystal, there are no linked crystal libraries. You compile your whole app, will all class definitions. The compiler then will have all the type information to know if a method is missing in a subclass, when that method is used from a parent class.

We (think we) have good reasons for that: https://github.com/crystal-lang/crystal/wiki/FAQ#why-isnt-th...

It will simply stop compiling the code and it will say "undefined method 'talk' for Snake". You will get a similar error if `talk` is defined as an abstract method in the base abstract class. So abstract methods are just a standard way to document this and to improve error messages. There's no safety hole here.

We mostly want to never have to do this. This way we can guarantee that "no method error" never happens at runtime (one of the most feared exceptions after a big refactor in a dynamically typed language)

Thank you for the detailed analysis!

Yes, Crystal will definitely need a lot of work. On the other hand, maybe this work is also fun :-)

Also there's the thing that Go has big Google behind it, so of course it's much more advanced (plus they also started earlier).

All the languages couldn't fit in the talk, but the full benchmarks are here:

https://github.com/kostya/benchmarks

As always, take benchmarks with a graint of salt. We use benchmarks mostly to know how far away we are from C (1x, 10x, 100x, etc.), so any language that has a speed "in the order of" C is good enough for us, small differences don't matter much.

It will never run Rails. Crystal is just heavily inspired by Ruby, but has already diverged in a lot of places in terms of syntax and semantics. Plus, Ruby has "eval" and "send", which Crystal don't and will (probably) never have.

The current HTTP server is pretty fast. Did you try compiling/running your program with the `--release` flag? It's explained a bit here:

http://crystal-lang.org/docs/using_the_compiler/index.html

Crystal is faster than Go in some cases (mostly because we use LLVM and it optimizes really well), but right now Go has faster context switches between goroutines (in our case fibers) and in general faster concurrency (for example it distributes the goroutines across multiple threads, we are using one for now). But improving these is definitely on our roadmap and should be doable.

More good news is that we are using Boehm GC and didn't spend a lot of time optimizing on our side (rather than just relying on LLVM), so a custom GC and more optimizations (like maybe escape analysis) could improve performance even more.