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.
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.
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?
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.
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)
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.
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.