[coldnebo]

The Ruby community is always likely to prefer MRI because that's the core that the majority of gems support.

So, yes, on the surface of it, this particular Ruby build might appeal to people looking for performance.

But from a language research position it is interesting to decouple concepts like GC from the language so that they can be studied and optimized as a pattern and then be potentially reapplied to any language runtime.

I agree that some concepts might be pulled into MRI Ruby 3, but OMR may be a powerful testbed for language researchers to debate GC strategies and measure effects in various languages before committing to a single language integration.

[magaudet]

Thanks! That's definitely the exact hope we have for OMR as well.

Similarly, improvements in OMR can be shared among all languages using it; ie, because we build both IBM's Java JDK and Ruby on top of OMR, Ruby can benefit from investment in Java, and Java can benefit from improvements in the Ruby community.

[dragonwriter]

> The Ruby community is always likely to prefer MRI because that's the core that the majority of gems support.

It may be worth rembering that today's (1.9 and later) "MRI" started life as an alternative to MRI called "YARV". For a while there was a lot of talk about Rubinius as potentially being the basis of a similar replacement and becoming the "MRI" of the future. While there is less talk recently about Rubinius in that role, its absolutely not impossible that a competing core engine could be adopted as the mainline implementation of Ruby again.

[ksec]

That is assuming,

1. It is mostly compatible with Gems. 2. It is faster and accepted by the Core Team. 3. Most importantly, license. Both MRI and YARV, the two CRuby implmentation are all MIT. It is highly unlikely JRuby or OMR could be used as mainline.