Charlie Nutter gives a good roundup of Ruby implementations past to present, with a few guesses as to the future.
I’ve played with four: 1.8/MRI, 1.9/YARV, JRuby, and Rubinius. What I found a bit surprising is that I’ve come to appreciate pieces of all of them. MRI is pretty stable and widespread. 1.9 allows me to play with OS threads faster. JRuby allows me to play with the JVM crowd (and push threads even more). And I think we all owe the Rubinius for the spec work.
But there’s one thing that having four versions has helped immensely with: writing Ruby with threads. Threads can be such a bloody pain to develop. In all but the simplest programs, it gets pretty tough pretty quickly to be sure there are no unexpected sequences of events. When you run primarily on one platform/library, you pretty quickly surface the low hanging fruit: the races/sequences that occur most frequently on that platform. But there are all those rarer cases that kill you. Since they’re rare, they’re typically gone by the time you notice them and it’s virtually impossible to get them to repeat. So you start to rationalize: maybe I didn’t really see it; maybe I misinterpreted what I saw. Maybe it was a side effect of something else I already fixed.
But in the back of your mind, you wonder if you’re lying to yourself.
It’s the stuff of nightmares, a monster you just know is hiding under your bed.
In the case of Ruby, we have four implementations that share a pretty solid thread model … with wildly varying dynamics. In developing some threaded code, I started on MRI and made it solid. And then ran on 1.9 and everything went to hell because things were happening in a different order. Ditto for JRuby. So far, the only case where I didn’t surface more corner cases was Rubinius, which either means I’m getting farther out on the latent bug curve or I simply haven’t run enough tests on it.
If you’re writing threaded code on Ruby and it’s feasible, it might be worth considering developing on more than one VM, even if you only expect to actually roll one VM into production.
Of course, avoiding writing-down-and-dirty with threads is not the only nor (arguably) the best approach to concurrency, but you already knew that …
Leave a Reply