Hacker News Reader

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.

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.

> 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.

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.

Interesting, For many years I was all in on MRI and down on JRuby but over recent years I've been quite happy with JRuby for certain things.

The reality of JRuby startup times make it not a good fit for scripting tasks but otherwise server and threaded tasks are a great fit. Since using JRuby more recently I feel the ecosystem support is probably the best of the non-MRIs. I rarely run into compatibility issues. Conversely JRuby's Java integration has been a very useful feature that no other Ruby implementation offers.

> or me, the differences between MRI and other implementations effectively make them different languages, I'd jump to Elixir before giving JRuby a shot

Wha? Sorry but this sounds pretty FUDdish. I have never had an issue with JRuby to the extent that you are describing. Do you have some examples?

I know of many large app deployments in JRuby at large household name companies.

The only thing JRuby doesnt have is the relatively niche CExt functions.

I use jruby on my hobby projects at time (GUI support is great!) however...the startup time is...always...so...awful...it is truly painful. I'm basically moving on to either crystal or go now, it just wasn't worth it anymore.

As somebody not into the whole ruby-ecosystems: What's an example that breaks compatibility between ruby and other implementations? And what's so wrong with JRuby that you won't even consider it?

Rubygems forms an ecosystem of libraries on top of Ruby. Most gems are dev/tested within MRI, some work across other Rubies, some do not. It's difficult to tell which is which. This means most teams choose MRI in much the same way that most Ruby teams choose some form of unix -- compatibility.

Ruby also suffers from the lack of a formal VM, so other implementations are merely similar rather than being guaranteed to run all programs. This is not the same with JVM vendors, where choice of IBM vs Oracle is largely based on extrinsic features rather than intrinsic compatibility. (Or at least you have to get in really deep to find differences-- in Rails you usually find incompatibilities that stop you from even starting the app).

Re: jruby

I have considered it deeply. Many of our enterprise systems are Java-based, so JRuby's ability to call Java methods directly without implanting services would be a huge pragmatic boon. But every time I consider that I have to balance it against being able to use a constellation of gems in Rails. For example, nokogiri (libxml) is used in a ton of stuff. Sure there are Java equivalents, but that isn't the issue. Rather I would have to reimplement or find replacements for everything we use that depends on that without introducing side-effects. In my experience that's really hard unless it's a toy application without many dependencies. (Read: opposite of most enterprise Ruby apps)

Also, as a gem author I've tried to support jruby along with MRI, but it requires jumping through a lot more hoops. Of course any cross-platform code requires more work to support, but it's a pressure on small devs. If no one needs it, no one helps support it, so then it becomes another gem that is effectively MRI-only. Kind of a viscous cycle.

> nokogiri (libxml) is used in a ton of stuff. Sure there are Java equivalents,

Nokogiri natively supports JRuby, no equivalent searching required.

CExts are basically the only place where this issue really pops up and all the major CExt gems (Like nokogiri) support JRuby.

+1 nokogiri works like a champ on JRuby

A different driver to the database for MRI and JRuby. Not a big deal.

The deal breaker for me is the very slow startup time for tests and no gains for run once scripts. I've seen people developing with MRI and doing CI on JRuby to work around that. It's worth doing that only if you have a service running with some real load. Most internal services do nothing almost all the time.