Crystal is only five years old.
Nim is 11, Rust is 9, Kotlin is 8, OCaml is 23 and Swift is 5.
Basically, Crystal is tied with Swift as the youngest.
What it offers right now is a simple porting process for those with Ruby codebases.
But, yeah, besides the syntax familiarity for Ruby programmers it doesn't seem offer much that the others do.
The "even OCaml" is what threw me. Still not quite sure if they meant older or younger from it.
> But, yeah, besides the syntax familiarity for Ruby programmers it doesn't seem offer much that the others do.
A familiar syntax is a huge benefit in a lot of contexts. There's plenty of Ruby-only shops around the world. Making a faster and statically-typed language accessible to them is a decent niche.
Crystal isn't quite Ruby. It has type guarantees that Ruby doesn't, which makes it easier to maintain. The async and parallel stories are also immensely better in Crystal than Ruby.
The "Nil is a compile-time error" is also a feature I highly appreciate.
Also, give your developers a more productive language that can go where Ruby can't (like OS development), which is 90% instantly recognizable — may also be worth something?
A rewrite in (other fast language) from Ruby sounds ridiculous as soon as you include writing a extra FFI wrapper around this you have to maintain so that would be out of the picture and that sounds a lot harder than a semi 1:1 port of the source code.
The trouble is Ruby itself is starting to become a sunken cost as a language but is survived because of Rails, thus also explains the countless memory issues that happen when developers use it. So for a stopgap to something sort of better, I would rather port to Crystal or Elixir so I can run on those low-cost VMs and save cash.
I just want to know if it is more than that or not.
I'm not a fan of Ruby and would prefer Nim or Rust if it were about syntax.
I ask myself if I miss any huge speciality of Crystal if I dismiss it just because of its syntax.
[0] https://crystal-lang.org/2014/06/19/crystal-0.1.0-released.h...
The main point was comparative age of languages. Like OCaml which is more than two decades old compared to Crystal which is young.
If you / most people don’t particularly like the Ruby-like syntax, then Crystal might not appeal to you. But I can assure you to those of us who like the syntax, the language is wonderful and super fun to work with.
Ruby’s syntax is a great fit for Ruby’s semantics but—and Ruby is my personal favorite language—I don't see much point for it divorced from that. It's the one thing I like least about Elixir.
OTOH, Crystal looks like it may be close enough to Ruby semantics that Rubyish syntax is a plus rather than a misdirection and distraction.
My Ruby code is like 95% chained higher-order array functions. My classes almost never have state. I'm basically writing functional code, and it seems like this is a pretty common paradigm in Ruby. I will say this was HEAVILY influenced by learning Elixir.
When not taking external libraries into account, my Elixir code (at least to me) seems almost identical to my Ruby code.
I think Python and Ruby are very close. But I personally think list comprehensions are un-intuitive and you can't easily chain higher-order array functions in Python.
So although I feel the spirit of my Ruby and Python code is identical, in no way do they look and feel identical. In the same way, I think my Elixir and Python are quite different.
Sample size of 1. I know. Just thought I'd share.
- Elixir has |> instead of method chaining
- Elixir uses "do [...] end" consistently for blocks (as opposed to Ruby omitting the "do" in front of function/module/class/etc. bodies)
- Elixir supports Erlang-style tuples on a syntax level while Ruby (AFAICT) does not
- Elixir supports Erlang-style pattern matching / destructuring while Ruby (last I checked) does not
- Elixir's a fair bit stricter about differentiating zero-argument function calls from variables (i.e. if it's ambiguous it'll complain)
That is to say, Elixir's syntax descends directly from Erlang and Ruby, just as Ruby's syntax descends directly from Eiffel and Perl, and it shows rather strongly. That should be unsurprising, given that Elixir is the creation of a (former?) Rails maintainer.
My point is that all this is normal, and all the languages I list have offered it for longer than Crystal.
Swift - crystal throws exceptions, swift explodes...
Ocaml - the functional approach is not for everyone.
Rust - I like rust a lot. But sometimes I want to write something quick and I'm happy to sacrifice some memory and speed to not have to deal with the ownership issues.
Nim - the most comparable, I guess it's syntax preference at that point
OCaml is pretty general purpose though, it has loops, objects, mutable state. libguestfs [1] and some other codebases (the compiler itself, btw) are written in a pretty imperative OCaml.
Personally, I am learning it now, and I think rather than it being a stepping stone between OOP and FP, it might as well be its own separate and hybrid paragdim; I find purer FP languages like Haskell much more intuitive than the mix of modules, objects, types and classes of OCaml.
Though do not get me wrong, OCaml is an amazing language. It just stands rather by itself.
Pardon my terrible english.
[0] https://kotlinlang.org/docs/reference/native-overview.html
The selling point for Crystal is that it has a clean syntax that's easy for Ruby or Python developers to pick up (almost the same as Ruby), but compiles to standalone binaries that run really, really fast.
I mostly work in Python because the libraries are a lot more mature, but I use Crystal when I need to produce a standalone binary.
In a world with Go, Rust, D, C++ and C, this part requires comparison with these other languages.
Faster than Ruby and faster than Python doesn't cut it.
What do these mean?
foo = ENV["FOO"]? || 10