Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Because there's always something different that needs to be done for them once your project starts becoming non-trivial. You might need a different version of a gem (e.g. pure-java Nokogiri), or they're behind recent MRI features. And if you care about concurrency, it's different everywhere.

In my personal experience I've found MRI to be the best experience simply because that's what most other people are using, and there's a lot to be gained from being in the mainstream.

Don't get me wrong- I would actually love for JRuby to become the de-facto Ruby implementation. So many headaches are caused by native code in gems. And we'd have a solid foundation for GC, concurrency, etc. But that's not the current reality.




Rubinius does not need Gem replacements like you need in JRuby, it still has a compatible CAPI.

> [...] or they're behind recent MRI features.

Part of this is due to MRI having literally no specification process at all. Python has the PEP system, no such thing exists in Ruby land. People tried to change this in the past (http://rubyspec.org/design/) but with little to no success so far. As a direct result of this there are only two ways to keep up to date with what changes in Ruby:

1. Follow every issue reported on bugs.ruby-lang.org, forever. 2. Wait until users report issues about something not being present, behaving differently, etc.

> And if you care about concurrency, it's different everywhere.

This is FUD. An implementation may offer different primitives for concurrency (e.g. Rubinius has Rubinius::Channel) but they also offer shared APIs. For example, the Thread class works across all implementations as you'd expect. Whether you use this on JRuby or Rubinius the end result is the same: proper concurrency.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: