Hacker News Reader

Comment by zizee | Hacker News Reader

Could you not make the same argument about JavaScript? JavaScript was pretty slow for many years. Google then put some significant engineering investment into the V8 engine, resulting in a huge increase in JavaScript's performance.

View on HN

I think JavaScript performance received very significant investments from the biggest players (Google, Apple, Microsoft, etc.) thanks largely to the fact that you can’t throw more compute at it — JavaScript has to run on crappy user devices developers can’t upgrade. Ruby (or Python) never received anywhere near the JavaScript level of investment in performance. Of course there are fundamental design limitations too.

With GraalVM around, niche languages can pretty much take advantage of the significant investment into the JVM. Its whitepaper is truly novel, but the gist of it is that one has to implement an AST-based interpreter for a dynamic language, and then it will make use of state-of-the art JVM GCs, JIT, etc. TruffleRuby is the fastest Ruby implementation around, GraalJS can after warmup match the performance of V8, so it is indeed a very interesting technology.

How is matching V8 performance a big deal given that MRI Rack isn't significantly slower than Node?

There's significantly more motivation to run JS faster since JS isn't a choice; if you need an interactive website, it will use JS. Ruby is a choice.

I guess everyone with significant investment in ruby codebases can just "choose" to rewrite everything in another language.

Whilst they are doing their multiyear rewrites, it would be nice if someone could optimise the ruby runtime a bit for them.

Of course the answer is positive.

But it will take a drastic / complete rewrite of the VM, as it happened to Chrome's and Firefox's JavaScript VMs.

This means many man-years, and a certain break in the continuity, maybe with small but noticeable deviation in the VM's behavior. If we squint just so, we can consider Ruby 3.0 to be such a rewrite.

Crystal is a similar rewrite effort, but a one that isn't trying to stay backwards-compatible.

For those of us with many man years of investment into existing Ruby systems, any further investment into speeding up the language's runtime and general evolution is welcome.

Reply on news.ycombinator.com