5 ms·

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 t

by cutler 5y ago

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?

canadianfella 5y ago
> 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.
- nine_k 5y ago
  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.
  - ZeroGravitas 5y ago
    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.
  - pjmlp 5y ago
    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.
zizee 5y ago
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.
- nine_k 5y ago
  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.
  - zizee 5y ago
    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.
- oefrha 5y ago
  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.
  - kaba0 5y ago
    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.
    - cutler 5y ago
      How is matching V8 performance a big deal given that MRI Rack isn't significantly slower than Node?
jaredcwhite 5y ago
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).
- joelbluminator 5y ago
  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.
  - bhaak 5y ago
    > he wants Ruby devs to feel good about themselves We don't deserve Matz. He's too good to be true. :)
- cutler 5y ago
  Interested in these benchmarks. Could you specify?
djur 5y ago
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.
- pjmlp 5y ago
  It is the option when syntax familiarity and similar language concepts count.
  - jashmatthews 5y ago
    Crystal is little like Ruby now.
kaba0 5y ago
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.
dragonwriter 5y ago
> 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.

by cutler 5y ago

canadianfella 5y ago

> 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.

nine_k 5y ago
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.
- ZeroGravitas 5y ago
  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.
- pjmlp 5y ago
  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.

zizee 5y ago

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.

nine_k 5y ago
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.
- zizee 5y ago
  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.
oefrha 5y ago
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.
- kaba0 5y ago
  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.
  - cutler 5y ago
    How is matching V8 performance a big deal given that MRI Rack isn't significantly slower than Node?

jaredcwhite 5y ago

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).

joelbluminator 5y ago
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.
- bhaak 5y ago
  > he wants Ruby devs to feel good about themselves We don't deserve Matz. He's too good to be true. :)
cutler 5y ago
Interested in these benchmarks. Could you specify?

djur 5y ago

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.

pjmlp 5y ago
It is the option when syntax familiarity and similar language concepts count.
- jashmatthews 5y ago
  Crystal is little like Ruby now.

kaba0 5y ago

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.

dragonwriter 5y ago

> 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.