Hacker News Reader

Comment by compay | Hacker News Reader

It's not like MRI 2.0 is right around the corner either. A lot of work will be needed to get 2.0 out the door - potentially years. That work could instead be applied to Rubinius, and the release schedule could end up being similar.

If it's "just a dream," it's largely for human reasons rather than technical ones.

View on HN

> If it's "just a dream," it's largely for human reasons rather than technical ones.

That may be true, but don't we all preach that "People matter, not technologies" all the time?

Nobody pretends that MRI 2.0 is round the corner, but rbx at the moment is not in a position to even replace MRI 1.9.2 (lack of windows support anyone?). Their current self-proclaimed status is 93% of the spec, so I don't think that stopping work on MRI and spending the next couple of month bringing RBX to the current MRI state is a valid alternative. Dropping MRI would also imply dropping the whole toolchain and all custom infrastructures based on MRI, lots of knowledge that people have with MRI would suddenly go worthless, etc...

I seriously don't see that coming in the next couple of years.

There are huge technological reasons as well. MRI is included in OS X, some Linux distros and even embedded in some systems. So there is a group of people that is interested in keeping exactly this system.

Also, I have yet to see a purely technological decision of that magnitude, even in the world of compilers.

I see Rubinius and JRuby winning the race, but I don't see any of them _replacing_ MRI.

MacRuby also already comes with OS X - though it's currently still a private framework. By the time MRI 2.0 is ready to be released, the world will be a different place, MacRuby could by that time be the default Ruby on OS X.

I understand there are good reasons to keep MRI around, but the idea of making Rubinius the future of core Ruby development is not an outlandish idea.

But you have noticed that MacRuby is an MRI fork?

Yes. What's your point?

Well, if rbx became the default implementation, lots of the effort that was invested in MacRuby would go stale. There's an incentive for the MacRuby people to keep investing into MRI since they can more easily adopt improvements from there. The benefit they get from taking code from MRI will diminish over time, but at least ATM I'd still expect it to be significant.

(note: I'm not following MacRuby Development very closely at the moment.)

While MacRuby is a fork, they have already replaced the VM with one that compiles to LLVM, which has been implemented in C++. They have also gutted things like String and Hash to use Objective-C's (or more precisely, Cocoa's) counterparts, and they have started using libdispatch (aka Grand Central Dispatch), Apple's open-source multicore tech.

One of the big things about the new VM is that it eliminates the global interpreter lock, meaning MacRuby probably has much better parallelization than MRI. With the VM alone I think they are on their way to being their own Ruby implementation.

All of this is a bit disappointing considering that they could have shared their improvements upstream and improved MRI performance for everyone, not just for Mac apps.

Reply on news.ycombinator.com