I'll put forward a more blunt answer: because Rubinius is the only tenable way forward, long-term, for Ruby.<p>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.<p>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.
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: <a href="http://docs.python.org/faq/library#can-t-we-get-rid-of-the-global-interpreter-lock" rel="nofollow">http://docs.python.org/faq/library#can-t-we-get-rid-of-the-g...</a>
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.