Hacker News Reader

Comment by cutler | Hacker News Reader

If you want fast Ruby it seems Crystal is your only option. Ruby is an interpreted language released in 1996 for scripting. Why are we surprised when attempts to shoe-horn it into something else (Ruby 3.0, JRuby, Truffle Ruby) fall flat?

View on HN

Ruby's basically as fast as Node.js. If you look at comparative benchmarks, Roda/Rack/Puma is within spitting distance of Koa, Fastify, etc. Express is actually slower in some benchmarks.

I don't think a lot of people are aware of just how much faster the Ruby ecosystem has gotten in the past few years (especially when you leave Rails out of the equation which is known not to do well in microbenchmarks).

I just heard Matz saying yesterday additional effort will be made to make Ruby run faster specifically on benchmarks. He said while they don't always correlate completely to real world performance, since developers seem to care a lot about benchmarks he wants Ruby devs to feel good about themselves and score well on these.

> he wants Ruby devs to feel good about themselves

We don't deserve Matz. He's too good to be true. :)

Interested in these benchmarks. Could you specify?

> If you want fast Ruby it seems Crystal is your only option.

Crystal may be fast, but its definitely bot Ruby. Choices for fast not-Ruby are not lacking.

> Why are we surprised when attempts to shoe-horn it into something else (Ruby 3.0, JRuby, Truffle Ruby) fall flat?

Weird that you don’t put Ruby 1.9+ on that list, though that is as much or more a switch from what immediately preceded it with parallelism as an improvement area as 3.0 is (sure, Ractors are a bigger language change, but going from green threads to native threads with a VM lock was a major implementation change.) The difference is that 3.0’s relevant improvements are still experimental and its easier to misrepresent “haven’t yet stabilized and seen wide production use” as “fell flat” than it would be to claim thr same thing about 1.9’s improvements. But its not true in either case.

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.

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.

Crystal isn't the "only option" for fast Ruby because it's not Ruby. If Crystal is an option, so are a lot of languages.

It is the option when syntax familiarity and similar language concepts count.

Crystal is little like Ruby now.

Since when did JRuby or Truffle Ruby fall flat? The article is about a given usecase/lib, that as others mentioned uses multiple processes, which doesn’t really favor a JIT runtime.

> Ruby is an interpreted language released in 1996 for scripting. Why are we surprised when attempts to shoe-horn it into something else (Ruby 3.0, JRuby, Truffle Ruby) fall flat?

Because Lua (1993) and JavaScript (1995) can be very fast.

To be just, Lua is drastically simpler as a language. A simpler language likely takes less effort to write an efficient JIT for its VM.

And javascript's speed seems mostly a result of throwing amazing amounts of smart engineers at it over time, rather than anything inherent in the language itself.

How is the state of LuaJIT since Mike's departure?

I don't follow Lua, but I got the feeling it is pretty much stuck on its last version.

Reply on news.ycombinator.com