3 ms·

Engine Yard's objective is to drive Ruby adoption as a whole. Everything they are doing with open-source aligns with this. Their current strategy seems to be b

Engine Yard's objective is to drive Ruby adoption as a whole. Everything they are doing with open-source aligns with this. Their current strategy seems to be based on three observations: 1. There are a lot of Windows users in the world and Ruby sucks on Windows. 2. There are a lot of existing companies using Java still and many are scared of Ruby. 3. Even if people get past 1 & 2 a lot of people are still scared off because "Ruby/Rails Doesn't Scale" (i.e., MRI is slow). They are executing against all three of these barriers with their various initiatives: 1. Make Ruby a better platform on Windows: Rails Installer, SQL Server ActiveRecord adapter and including Windows as a target platform for their VMs. 2. JRuby as a gateway drug to the Land of Ruby; _could_ end up being VM winner too. 3. Rubinius as a possible MRI replacement, if they can make it technically superior and rally support within the community. (Think Merb -> Rails 3) With this in mind, it makes perfect sense for them to support both JRuby and Rubinius. It also makes sense for them to not be too overt about at least some of these goals. (See Merb vs Rails compared to SlimGems vs RubyGems.)

ssmoot 15y ago
> JRuby as a gateway drug to the Land of Ruby; _could_ end up being VM winner too. I don't get the "could". JRuby is among the fastest, gives you access to a massive amount of OSS and infrastructure, and fixes Ruby's threading. It's done these for years at this point. In my mind the question is more along the lines of "why should I use anything _but_ JRuby on a new project?". It's blasphemy I'm sure, but I just don't see the point in C-Ruby for new development at this point. It's legacy. JRuby, as the last-man-standing among the major Ruby VM implementations now that IronRuby is dead and everything else is vapor (Maglev) or niche (MacRuby) is the default modern Ruby implementation to my mind. So let's assume Rubinius is great, and the GIL is clearly a major step forward. Is EngineYard's intent really to supplant YARV with Rubinius? Because that sounds great to me. I've never seen EY say that though (they might have and I just missed it). If that's the vision, I'd rather see them come out and say it. Having developers guess, and having any ambiguity at all around the future of these projects and the messaging surrounding them doesn't inspire confidence.
- mitchty 15y 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.
  - headius 15y ago
    Well put. JRuby and Rubinius both have rich futures ahead of them, and they're going to be largely separate. 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.

ssmoot 15y ago

> JRuby as a gateway drug to the Land of Ruby; _could_ end up being VM winner too. I don't get the "could". JRuby is among the fastest, gives you access to a massive amount of OSS and infrastructure, and fixes Ruby's threading. It's done these for years at this point. In my mind the question is more along the lines of "why should I use anything _but_ JRuby on a new project?". It's blasphemy I'm sure, but I just don't see the point in C-Ruby for new development at this point. It's legacy. JRuby, as the last-man-standing among the major Ruby VM implementations now that IronRuby is dead and everything else is vapor (Maglev) or niche (MacRuby) is the default modern Ruby implementation to my mind. So let's assume Rubinius is great, and the GIL is clearly a major step forward. Is EngineYard's intent really to supplant YARV with Rubinius? Because that sounds great to me. I've never seen EY say that though (they might have and I just missed it). If that's the vision, I'd rather see them come out and say it. Having developers guess, and having any ambiguity at all around the future of these projects and the messaging surrounding them doesn't inspire confidence.

mitchty 15y 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.
- headius 15y ago
  Well put. JRuby and Rubinius both have rich futures ahead of them, and they're going to be largely separate. 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.