That's very interesting! It seems that big Ruby shops like Shopify and Stripe are investing a lot on improving Ruby's performance. Here is a tweet from Stripe's CEO regarding the performance of their custom Ruby compiler <a href="https://twitter.com/patrickc/status/1410269843585069056?lang=en" rel="nofollow">https://twitter.com/patrickc/status/1410269843585069056?lang...</a>
Just in case anybody finds the subject interesting and would like to play with this topic, there's an experimental native-Ruby JIT project by @tenderlove: <a href="https://github.com/tenderlove/tenderjit" rel="nofollow">https://github.com/tenderlove/tenderjit</a> (and the companion native-Ruby assembler Fisk: <a href="https://github.com/tenderlove/fisk" rel="nofollow">https://github.com/tenderlove/fisk</a>), which is (IMO) considerably easier to work with.
This is so exciting to see! I'm excited about the internal changes to MRI to unlock even bigger performance. I'd also love to see some research on what FFI changes would be helpful for enabling more performance across the FFI boundary. A lot of conversation ends up at "well, we go into C and it's terrible" but that feels defeatist.
Is the main difference in performance between JS and the others (Perl, Ruby, PHP) the fact that JS is JIT'ed and the others are not? I mean JS used to be slowish and until V8 came, what is V8 doing? Why can't Python / Ruby do the same thing?
How many Jit compiler attempts did we already see? It seems to me there has never been substantial progress towards speed or is it just that other languages implementations increase speedwise at the same pace?<p>Source: Computer Languages Shootout
It's a bit late. If it was released by the time Rails was hip and cool it would for certain help with Ruby adoption and retention. But people in search for new and shiny thing jumped ships already to platforms such as Node.js which has decent performance.<p>Even for PHP the new VMs and speed improvements might be too late.