Plus points for having all code generation flags in the standard implementation, instead of requiring a debug build like on V8, or an additional plugin like on most JVMs.
We already have TruffleRuby and JRuby using advnaced JITs courtacy of the JVM. Whilst both show that amazing things are possible I think Crystal is still ahead of both in terms of raw performance.
The best reason to use either Ruby or Crystal is because you want to and leave it at that.
Language religious wars are idiotic, but pros/cons tradeoffs should be discussed .
There is/was a great deal of fragmentation. TruffleRuby is built on awesome tech, to be sure. Rubinius (rbx) and JRuby were awesome too. I remember the grand attempt by RedHat to make TorqueBox a better, enterprisy Rails platform on JRuby.
Yeah, Crystal is neat when it works, based on a slightly different language, static compilation, and LLVM. The gotchas include: it's too incompatible with Ruby to be a drop-in replacement, has numerous language oddities and deficiencies, and tends to uncover runtime bugs within minutes of use. I think for needing speed and after profiling a critical section to replace with native code, it's better to opt for a native extension such with Rust and https://usehelix.com to use with standard Ruby (mri).
Hopefully, 3.5-dev+ zjit bears fruit.
I don't do much Ruby development anymore because Elixir and Rust exist. (And also rustler!)
sabslikesobs•8mo ago
> YJIT can make Ruby code run faster, but this is a balancing act, because the JIT compiler itself must consume both memory and CPU cycles to compile and optimize your code while it is running. Furthermore, in large-scale production environments such as those of GitHub, Shopify and Stripe, we end up in a situation where YJIT is compiling the same code over and over again on a very large number of servers, which seems very inefficient.
> In this presentation, we will go over the design of ZJIT, a next generation Ruby JIT which aims to save and reuse compiled code between executions. We hope that this will help us eliminate duplicated work while also allowing the compiler to spend more time optimizing code so that we can get better performance.
Seems pretty cool. I haven't run into any these limitations in my own usage really, but I'm working at very small scales.
MarkSweep•8mo ago
That’s the way a lot of the optimization problems work. If you have a sever or two, the efficiency is not such a big deal. Once you have a lot of servers, making Ruby a few percents more efficient reduces the number of servers you need and thus justifies paying people to optimize Ruby.