|
|
|
|
|
|
by mitchty
5484 days ago
|
|
|
It's blasphemy in that your use of JRuby is inconsequential to rubinius. Not everyone uses JRuby, and the non JRuby using world would like the GIL thread locking abilities in their interpreters without java+JRuby. Native c/c++ ruby isn't legacy in everyone's environments, just perhaps yours. Why does EngineYard need to justify both implementations? I don't use JRuby at all outside of occasional curiosity. But I'm also not calling it useless in the same way you're basically attacking any non JRuby ruby implementation, which apparently includes MRI. Which is arguably the "default" implementation. Language implementations aren't a zero sum game. Work on one doesn't mean we can't have another. I don't see the Python people complaining about PyPy and vice-versa, they both serve their purposes. Anyway off to bed. |
|
|
If you want to use C extensions, Rubinius will be a better fit since it matches the MRI process model better. Rubinius will also map more directly to underlying OS APIs and quirks than JRuby, since we have to either use the JVM's vanillified versions of APIs or do the hard work of routing around the JVM with our own native libraries. And if you're a Rubyist looking to hack on internals, Rubinius is certainly more approachable right now. We hope to implement more of JRuby in Ruby in the future, but we'd need a really good reason to throw out fast, working code to make a move right now.
If you want to run an entire Rails site in a single process, JRuby's going to be the best option for a long time. C extensions required for native Ruby impls to interface with databases, etc, will always force trade-offs in memory management, concurrency, and process models. Those trade-offs do not exist when running on JRuby and using Java equivalents of those libraries. As a rule of thumb, the more unmanaged code you have in your application, the more hassles you're going to have. Native impls do almost all their interaction with the outside world via unmanaged code (C exts for DB access or fast memcaching, C-accelerated servers like Thin or Unicorn, etc). That's a problem.
If you just want to run some Ruby code, both implementations are going to serve you well. You're going to need to evaluate all options before deciding, and both implementations are going to be excellent Ruby implementations first and differentially interesting platforms second. And therefore, as you say, it's not a zero sum game. We'll all bring different features and weaknesses to the table, and users will choose which impl fits their needs best.