It's somewhat similar to Ruby, but it categorically is not Ruby. If you want fast compiled Ruby, TruffleRuby is actually Ruby and relatively compatible with MRI.
Like every one else I also used ruby for almost everything back then, usually some hundred of lines or less for processing stuff. but for tasks that run for several hours using ruby was a frustrating experience. slowness and memory consumption aside, the duck typing system and lazy evaluation of method meaning you can run to typo after hours of running session. sure, you can fix it by write the code more carefully, running smoke tests beforehand and other stuff, but it still a chore, and when you write code all days it makes you sloppier.
having a strong typed compiled language helps it immensely, and with crystal you don't have to sacrifice the easiness of programming. and you can compile it to a portable binary and run it everywhere, no need to reinstall a huge toolchain again. (yeah rust or go can also do that, but not for ruby level expressioness language)
I'm sure crystal is not the ideal language for everything you want to use, and ruby is still helpful for what you use daily. but for some tasks, crystal surely has it own advantages. you can write very capable CLI programs without have to install a single library!
But my main point was that people who do want a fast Ruby should be aware that Crystal isn't a Ruby in any meaningful sense - if you like Crystal for Crystal, by all means use it.
also, using crystal you have parallel and concurrency to speed up your task. sure it is not as good as other matured languages, but it still does the job.
when doing with large amount of data, and with IO involved, you will see that your JIT or AOT engine for ruby still can not cut it, because in ruby there is so many layers of safety check and failure guard it is really hard to make it faster (number calculation is not everything). with crystal you can manipulate the io stream directly, avoiding a lot of intermediate steps. you can check yourself, they make a full page for it: https://crystal-lang.org/reference/1.22/guides/performance.h...
personally I do not use a single language, I just pick the most suitable language for the job I'm doing, let it be ruby, python, crystal, rust, go or typescript. but surprisingly crystal is the one I use the most everyday.
How about the crashes for all the other more common reasons? It seems like a concern unrelated to whether a language is strictly AOT-compiled or not, and whether such compilation runs through a static type checker or not, and in any case surely differs a lot among programmers' experience. (Crashes from typos basically rarely if ever happened to me in Python, same with memory constraint crashes. But I've never tried running Python on anything with less than 1 GB/core, if you don't count possibly some educational usage on ancient 90s hardware or a 2004 laptop; the lowest power device was probably a Cubietruck3 from 2013 that still had a generous dual-core ARM cortex-a7 and 2 gigs.)
But I agree with the sentiment, I hate it when programs crash and take out their work in progress or other state. I wish more languages adopted the Common Lisp condition system model, where errors don't crash or unwind anything by default and you can dynamically fix things and retry, or resume, or restart from a specific stack frame. There's even a book about implementing it: https://www.amazon.com/dp/B0DF5YVJKJ (And despite being dynamically typed, Common Lisp is compiled to native machine code, and some implementations like SBCL offer some bare-bones static checks to flag trivial typo or type mismatch issues during compilation, before running the code in question... You can also bolt on a full static type system language on top as a library if you want.)
If your code is poorly enough tested for a typo to cause it to crash, a typo is the least of your concerns.
> also, using crystal you have parallel and concurrency to speed up your task. sure it is not as good as other matured languages, but it still does the job.
So you do in several Ruby implementations.
> when doing with large amount of data, and with IO involved, you will see that your JIT or AOT engine for ruby still can not cut it
I've used Ruby for large scale IO with Ruby for 20 years without problems, even on CPU's far slower, and with Ruby versions far slower than today. If you're doing IO with Ruby and the performance of your language implementation is what is limiting you, rather than spending most of the time in kernel space waiting for system calls to complete, you're doing something wrong.
Could also use Matz's Spinel Ruby compiler. That's Ruby with static types using RBS but you have to give up some metaprogramming to get it.
I love the idea that we could get ractors written with Spinel and compiled ahead of time. I also love the idea that I can use Ruby for self contained binary tools.
(And for the sake of avoiding confusion, Crystal is also a great project. I'm really pleased to see them continue making progress).
https://youtu.be/XVaRRryB_cQ?si=CuXiMDdwccH6wOra&t=760
Basically he's saying static typing is needed for AI today because it's "junior level", but for senior level programmers they are more experienced so these types blend into the background; therefore when AI is a senior level in the future, it will also not require static typing to not make mistakes. That writing correct code will be as natural to the LLM as moving your arm is to you.
And in what concerns interpreted languages, they will be replaced by agentic runtimes as it is already the case in iPaaS cloud products.
Though it makes it harder to generate fast code, it's not impossible given that most Ruby meta programming runs early and then doesn't change the program again, and most patterns are recognisable and it seems likely to be (I'm on and off working on my own Ruby AOT compiler) possible to statically verify for most programs that after a given point most code will not change types and so do static type inference to elide most type checks (a type in such a Ruby program will not be a given class, but a given version of a given class or meta class)