In fact being similar to or compatible with Ruby is not a language goal at all.
Crystalist: "Crystal is very Ruby-inspired. Welcome Ruby devs! What makes Crystal great is it's as fast as alternatives to Ruby, without sacrificing Ruby syntax and functionality! Port over your Ruby code! Crystal is Ruby on steroids!"
Rubyist: "Why does Crystal diverge from Ruby here, here, and here unnecessarily if the goal is to be similar to Ruby and allow porting more easily?"
Crystalist: "Crystal is not Ruby. Crystal has no goal of being similar to Ruby. Any similarity to other languages is purely coincidental. What's Ruby?"
On one hand, when they explicitly state that the goal is not for Crystal to be as close to Ruby as possible, that makes me more sympathetic.
At the same time it also makes me less likely to use it anytime soon. Not out of ill will - it's an interesting project and I hope they do well - but hardly any of my Ruby code is CPU constrained, so I have little reason to switch for speed. Had they aimed as close as possible, I might have tried anyway, but every little extra difference makes it less worthwhile.
Of course that's very different for people that actually write code where speed is a major concern and that e.g. haven't been able to use Ruby for that reason.
All of the IO in crystal is async, so even if you're IO bound, crystal is probably a lot more efficient.
In Ruby, MRI multiplexes over async IO if you use sync IO primitives, and using async IO directly is not a problem.
In any case, most of my code wait on external events (clients, databases) so it's very rare for the Ruby part to be worth optimising. I spend a lot more time doing things like optimising database indexes and the like.
Of course there are plenty of areas where the balance there would be very different.
The message we want to get across about the Crystal is that it is very Ruby-inspired, and that Ruby devs will feel at home. Crystal is often compared to Rust and Go, and the level of abstraction you will see when writing Crystal code will feel much more at home compared to Go and especially Rust. That being said, Crystal isn't Ruby, and you'll have more success writing a project from scratch for Crystal than attempting to port any >10k LOC codebase. Crystal isn't designed to make porting Ruby easy, and it hasn't been for a while. Crystal's goal is to make you as a Ruby developer feel at home, not your code. A lot of people have ported codebases from Ruby and talked about it, but you probably see only the successes, not the failures.
In short, we want you to use Crystal not because it's faster and easy to port to, but because it's simply a better, more robust, modern language.
Rust is very much a systems programming language: no GC, no runtime, no overhead. We don't intend to compete with Rust at all.
Go however has inspired Crystal's IO system quite a bit. Crystal looked at Go and saw that CSP was working very well and copied the idea.
Here's some differences:
- Go aims for simplicity, in Crystal it's a bit lower down the priority list in favour of expressability
- Crystal has a stronger, more complex type system than Go
- Crystal has type inference
- Crystal has blocks/yield (with 0 overhead) like Ruby
- Crystal has a more "normal" package manager