I'll put forward a more blunt answer: because Rubinius is the only tenable way forward, long-term, for Ruby.

MRI is a steaming pile. (Note: You're not allowed to disagree with this unless you're a C programmer that's spent some quality time with MRI's code.) It seriously shook my faith in Ruby the first time I had to dive into MRI's code: "Could someone who waxes poetic about elegance and fun in coding really produce something this fugly? Does Matz have any idea what he's talking about?" Rubinius has a sane design and is a pretty clean base to build a Ruby implementation with some staying power on. I basically see Rubinius as the rewrite that MRI was going to have to have at some point.

That said, at present, I still use MRI. I try Rubinius every couple months to see how it's progressed performance-wise for the cases that I care about, and while it's not there yet, this seems to be mostly a matter of time.

I'm all jruby all the time these days, and I couldn't be happier.

How do you feel about YARV? I mean, Matz has always been honest that he's not a compiler guy...

That said, I think rbx is the way forward too.

my hopes for the future are in RBX but why would the ugliness of MRI (I assume you include yarv in it) make it untenable in the long term?

There is a massive amount of bad code on the intertubes that has been around for decades, and I kind of hope we will not be programming in ruby when it's 40 years old.

How is Rubinius going to tackle the GIL issue? They say they're working to get rid of it, but I'd assume that a sizable chunk of the Ruby standard library isn't thread safe, especially C extensions. I guess I'm just not sure how they plan to avoid the issues that Python faces: http://docs.python.org/faq/library#can-t-we-get-rid-of-the-g...

A few points:

a) The ruby standard library is written in Ruby and is actually surprisingly well-behaved from a threading perspective. The code is not super-pretty, but it uses appropriate locking strategies and has been well-tested in threaded environments. All three major implementations (JRuby, MRI and Rubinius) share the vast majority of the Ruby standard library, so if JRuby works, Rubinius will work.

2) For the part of MRI written in C (which Rubinius calls the "kernel"), Rubinius has reimplemented the entire thing mostly in Ruby with some primitives. Since they own that code, it is their responsibility to define its semantics when run in parallel.

3) Rubinius implements its locking classes (like Mutex and ConditionVariable, see https://github.com/evanphx/rubinius/blob/master/lib/thread.r...) on top of its own low-level Channel implementation (see https://github.com/evanphx/rubinius/blob/master/kernel/boots...), which can be used to implement more sophisticated locking strategies. They have been working on this for a long time, and have been planning for it even longer.

grandparent was probably thinking of how you avoid the GIL if existing extensions are written expecting to be used by a single thread.

Since rubinius provides the same C-api ruby does (ignoring FFI for now) wouldn't all the accesses to external libraries need to be wrapped in a shared big lock?

For the time being, we use a lock that has to be held to run methods defined in C extensions, a GEL (Global Extension Lock) if you will.

We've got some other ideas to increase concurrency in extensions, but the crux is that yes, we have to perform some locking because people wrap thread unsafe libraries.

Because Rubinius does not use the C-API to implement anything in the core, this doesn't impact general concurrency.

That CPython faces. Neither Jython nor IronPython have GILs, and it should be much easier to remove PyPy's.

Another great read by Brian Ford. I mainly use MRI 1.9, but I have been experimenting with Rubinius of late. And it is getting better and better. Not only is the way Ruby in implemented cool, but the VM upon which languages like Fancy are being written is very exciting for the Ruby community.

Why not use http://jruby.org?

C extensions are a very big reason why not; the pain of demand-starting JVMs is another minor reason.

I suppose it depends on what you're using ruby for. I use it for long running processes like rails apps so the jvm startup time really doesn't matter. And jruby has support for c extensions that use ffi.

Nobody's saying not to use jruby. You asked a question, I gave one answer.

The second is actually much less painful than people generally think. Jruby -e 'some code' only takes half a second on my machine, which is fast enough to not be a problem. The main slowness people experience has to do with loading gems, usually via rubygems. That is painfully slow, but does not have anything to do with JVM startup time.

"jruby -e 1", cold start, just took 4 seconds for me. I use jruby interactively almost every day (it's extremely handy in penetration testing), and I'm pretty sure jruby is noticeably slower to start than MRI.

It's definitely noticably slower, but 4 seconds per startup would make it unusable for me. However, since it's

  time jruby -e 1
  real	0m0.514s
  user	0m0.510s
  sys	0m0.040s

I find it acceptable (could it be the SSD in my laptop that makes such a large difference?). As http://jira.codehaus.org/browse/JRUBY-5181 shows, as soon as some gems come into the picture, actual startup times deteriorate rapidly.

I'm not an SSD, but mine was also a cold start; are you sure yours wasn't already cached?

I don't reboot that often, so it took me a while before I could try it, but my home desktop, also with SSD, gives

  user@twen:~/tmp$ time jruby -e '1'

  real	0m0.664s
  user	0m0.390s
  sys	0m0.110s

for a cold boot. Subsequent startups are 350-400ms. Stock JRuby 1.5.6