From: Charles Oliver Nutter <headius@...>
Date: 2011-10-26T07:22:31+09:00
Subject: [ruby-core:40383] Re: [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2.0

On Tue, Oct 25, 2011 at 5:15 PM, Eric Wong <normalperson@yhbt.net> wrote:
> More seriously, I agree that Ruby should be used whenever it makes sense
> and I feel MRI uses too much C.

I agree wholeheartedly. This is perhaps the biggest reason I want MRI
to phase out the current C extension API in favor of one that's less
invasive, and why I'm excited for any promising JIT work for MRI. If
MRI can run Ruby fast enough, there will be less motivation to keep
moving libraries into C. That will make my life (and Evan's life) a
*whole* lot easier.

> However, I still spend more time with MRI (than Rubinius) for the
> following reasons:

And those are also reasons I don't think MRI will go away any time
soon. Suggestions to the contrary are just plain silly.

MRI is the most compatible Ruby implementation.

MRI is for many things still the fastest Ruby implementation (startup
time, some POSIX situations, C extensions).

MRI has the largest pool of regular contributors.

MRI is a solid, known quantity.

I will often recommend MRI when people need things that MRI does
better than JRuby, like fast startup, low-level POSIX stuff, or
features we can't support like callcc and fork. MRI is a vitally
important part of the Ruby implementation world.

Now, it would be nice if MRI didn't make changes to "Ruby the
language" without some direct participation and buy-in from the other
implementers, but that's a completely separate issue.

> With better Ruby APIs (like String#byteslice in 1.9.3) and proposed
> non-blocking IO methods[1], I think more parts of MRI could be
> implemented in Ruby without significant performance loss.

Agreed. And those APIs could easily translate to other
implementations, giving us a much smaller implementation target to
keep up with. Let's make it happen!

- Charlie