6 ms·

Obviously great news. It dampens my enthusiasm a bit to know the same company funds development of JRuby however. EngineYard really should clarify their vision

by ssmoot 15y ago

Obviously great news. It dampens my enthusiasm a bit to know the same company funds development of JRuby however. EngineYard really should clarify their vision behind maintaining two VMs. Going beyond the obvious "JRuby is for integration with existing J2EE infrastructure" angle would be nice. Under what circumstances would they actually stand behind Rubinius as the better choice? Is the MRI C extension API compatibility an official feature now? Is it that I could switch from REE to Rubinius without having to worry about finding alternatives for all the libs I'm using that carry C-extension baggage?

tptacek 15y ago
This is confusing. JRuby is a great and important project. It's how a several very large Rails apps ship deployable versions of their product; it's the easy way to get a Rails app deployed in shops where the normal mechanism for getting deployed is "submit a war file", and it's how you get Ruby access to a zillion Java libraries. Rubinius is a native implementation of Ruby that seems, over the long term, to have a goal of being the best single implementation of the language all other things being equal. Why would I ever want to penalize a company for funding both of these awesome projects?
- ssmoot 15y ago
  I didn't say anything about penalizing. Microsoft clearly differentiates versions of SQL Server. That's all I'm asking for. If JRuby performance continues to match or exceed Rubinius performance, but JRuby also gives me deployment flexibility and Java OSS integration options Rubinius doesn't, why would I choose Rubinius for my next green-field project? That's not an accusation. It's a serious question. I think Evan's answer on the Ruby C API is a pretty compelling reason on it's own. For businesses that don't have an easy JRuby migration path because of dependencies on multiple gems with C-extensions, maybe Rubinius is a much easier way to get into the next JRuby/Rubinius/YARV Ruby performance bracket. That can be very compelling on it's own. What are some other reasons I might consider Rubinius? Given the down-votes I guess I'm in the minority, but I think it's a fair question. I was an early supporter of Rubinius, and put my money where my mouth was on more than one occasion with cash donations to the project. I get that it's very neat from an academic standpoint. No argument here. Is it something EngineYard is going to stand behind and just as importantly, start marketing so I get a good feel for the practical uses?
  - mitchty 15y ago
    For my needs, jruby will never suffice as java isn't going to be installed on the servers I'm on. Nor to be honest would I want it, and JNI for c extensions is also a nonstarter. We have puppet at work for server deploys, and well, jruby may suffice for web/app server deploys that just run rails. But not all ruby users actually give a rats about rails (that's me, don't use it at all at work), nor do we have a need for java interop. Basically I'm in the exact opposite of your vantage. I need c bindings for a few gems I made that need c ffi bindings, I don't need/care/use any java interop, and personally, I'd rather not have the jvm running on any of my servers. I look at rubinius as the eventual YARV for the compiled version as YARV was to MRI, not as an academic project. But I admit, I seem to be a ruby outlier ever since rails has been around.
    - ssmoot 15y ago
      I don't use Rails. I see the JVM as a tool that gives me access to code I might find useful, and web-servers that are (IMO) 1000X superior to anything available to MRI. That and much better performance than REE anyways. If you need C-extensions, well, there you go. Rubinius as a better MRI I totally get/agree with. I think we agree on that as a good reason for the season for Rubinius. It'd just be nice for EY to put up a "Why Rubinius?" page. And further, a "Which VM best targets my project? JRuby or Rubinius?" page would make me very happy. I can't imagine it could hurt the adoption of either.
    - andrewvc 15y ago
      Jruby is working on cext support
      - headius 15y ago
        C ext support shipped in an "experimental" form in JRuby 1.6. The main problem is that C extensions suck in so many ways: * Can't have multiple VMs in process, because C exts load all their state into C globals * Can't run them concurrently, because they can't be trusted not to segfault * Don't participate well in modern GCs, so they have significantly higher call overhead in JRuby or Rubinius than they do in MRI FFI is a better option in almost every case, although it is admittedly a much trickier path to cross-platform library binding. The best thing the Ruby community could do to move Ruby forward is to either come up with a better C API or start using FFI for everything. C exts suck.
- sandGorgon 15y ago
  I'm not sure if what I'm thinking is correct (or even technically possible) - but couldnt it be possible that what they are envisioning is the Rubinius architecture being the one true Ruby and having two backends : C-Rubinius or Java-Rubinius. What it would mean is that the C-Rubinius and Java-Rubinius releases be simultaneous: you can choose to pick one or the other based on your surrounding stack. This would mean that they fund both Jruby and Rubinius till they can be merged.
evanphx 15y ago
The MRI C extension API compatibility is very much an official feature. Except for a few gems we can't make work (because they tie directly into 1.8's execution model) most work fine. If you have one that doesn't work, please just open an issue and we'll figure it out!
- ssmoot 15y ago
  Very cool. Been a long time coming, with a lot of blood sweat and tears on your part, but it looks like Rubinius2 is the project I was lusting after those years ago, back when it looked like Sydney was the fix for what ailed Ruby. ;-) Congrats on the milestone!
krohrbaugh 15y ago
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
bad_user 15y ago
Is the MRI C extension API compatibility an official feature now? Yes, because there's lots of code out there that's targeting that API and you don't want to throw good, stable and tested code away. without having to worry about finding alternatives for all the libs I'm using that carry C-extension baggage It's not really baggage that you don't want. It's only baggage in the sense that backwards-compatibility makes forward progress harder, but if you can come up with a way to maintain compatibility with an emulation layer of some sort, than that's the best of both worlds. EngineYard really should clarify their vision behind maintaining two VMs It's not EngineYard's business to clarify their vision behind these 2 VMs, as both projects were started outside of EngineYard. This company is doing the Ruby community a favor by paying developers for working on these 2 projects, but the projects themselves would go on without EngineYard.
mark_l_watson 15y ago
As a Ruby developer, it is important for me to have options on deployment and also support for using large C/C++ libraries (e.g., Redland RDF) or large Java libraries (e.g., machine learning, Sesame RDF, etc., etc.) Great to have MRI C, Rubinius, and JRuby.

by ssmoot 15y ago

tptacek 15y ago

This is confusing. JRuby is a great and important project. It's how a several very large Rails apps ship deployable versions of their product; it's the easy way to get a Rails app deployed in shops where the normal mechanism for getting deployed is "submit a war file", and it's how you get Ruby access to a zillion Java libraries. Rubinius is a native implementation of Ruby that seems, over the long term, to have a goal of being the best single implementation of the language all other things being equal. Why would I ever want to penalize a company for funding both of these awesome projects?

ssmoot 15y ago
I didn't say anything about penalizing. Microsoft clearly differentiates versions of SQL Server. That's all I'm asking for. If JRuby performance continues to match or exceed Rubinius performance, but JRuby also gives me deployment flexibility and Java OSS integration options Rubinius doesn't, why would I choose Rubinius for my next green-field project? That's not an accusation. It's a serious question. I think Evan's answer on the Ruby C API is a pretty compelling reason on it's own. For businesses that don't have an easy JRuby migration path because of dependencies on multiple gems with C-extensions, maybe Rubinius is a much easier way to get into the next JRuby/Rubinius/YARV Ruby performance bracket. That can be very compelling on it's own. What are some other reasons I might consider Rubinius? Given the down-votes I guess I'm in the minority, but I think it's a fair question. I was an early supporter of Rubinius, and put my money where my mouth was on more than one occasion with cash donations to the project. I get that it's very neat from an academic standpoint. No argument here. Is it something EngineYard is going to stand behind and just as importantly, start marketing so I get a good feel for the practical uses?
- mitchty 15y ago
  For my needs, jruby will never suffice as java isn't going to be installed on the servers I'm on. Nor to be honest would I want it, and JNI for c extensions is also a nonstarter. We have puppet at work for server deploys, and well, jruby may suffice for web/app server deploys that just run rails. But not all ruby users actually give a rats about rails (that's me, don't use it at all at work), nor do we have a need for java interop. Basically I'm in the exact opposite of your vantage. I need c bindings for a few gems I made that need c ffi bindings, I don't need/care/use any java interop, and personally, I'd rather not have the jvm running on any of my servers. I look at rubinius as the eventual YARV for the compiled version as YARV was to MRI, not as an academic project. But I admit, I seem to be a ruby outlier ever since rails has been around.
  - ssmoot 15y ago
    I don't use Rails. I see the JVM as a tool that gives me access to code I might find useful, and web-servers that are (IMO) 1000X superior to anything available to MRI. That and much better performance than REE anyways. If you need C-extensions, well, there you go. Rubinius as a better MRI I totally get/agree with. I think we agree on that as a good reason for the season for Rubinius. It'd just be nice for EY to put up a "Why Rubinius?" page. And further, a "Which VM best targets my project? JRuby or Rubinius?" page would make me very happy. I can't imagine it could hurt the adoption of either.
  - andrewvc 15y ago
    Jruby is working on cext support
    - headius 15y ago
      C ext support shipped in an "experimental" form in JRuby 1.6. The main problem is that C extensions suck in so many ways: * Can't have multiple VMs in process, because C exts load all their state into C globals * Can't run them concurrently, because they can't be trusted not to segfault * Don't participate well in modern GCs, so they have significantly higher call overhead in JRuby or Rubinius than they do in MRI FFI is a better option in almost every case, although it is admittedly a much trickier path to cross-platform library binding. The best thing the Ruby community could do to move Ruby forward is to either come up with a better C API or start using FFI for everything. C exts suck.
sandGorgon 15y ago
I'm not sure if what I'm thinking is correct (or even technically possible) - but couldnt it be possible that what they are envisioning is the Rubinius architecture being the one true Ruby and having two backends : C-Rubinius or Java-Rubinius. What it would mean is that the C-Rubinius and Java-Rubinius releases be simultaneous: you can choose to pick one or the other based on your surrounding stack. This would mean that they fund both Jruby and Rubinius till they can be merged.

evanphx 15y ago

The MRI C extension API compatibility is very much an official feature. Except for a few gems we can't make work (because they tie directly into 1.8's execution model) most work fine. If you have one that doesn't work, please just open an issue and we'll figure it out!

ssmoot 15y ago
Very cool. Been a long time coming, with a lot of blood sweat and tears on your part, but it looks like Rubinius2 is the project I was lusting after those years ago, back when it looked like Sydney was the fix for what ailed Ruby. ;-) Congrats on the milestone!

krohrbaugh 15y ago

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

bad_user 15y ago

Is the MRI C extension API compatibility an official feature now? Yes, because there's lots of code out there that's targeting that API and you don't want to throw good, stable and tested code away. without having to worry about finding alternatives for all the libs I'm using that carry C-extension baggage It's not really baggage that you don't want. It's only baggage in the sense that backwards-compatibility makes forward progress harder, but if you can come up with a way to maintain compatibility with an emulation layer of some sort, than that's the best of both worlds. EngineYard really should clarify their vision behind maintaining two VMs It's not EngineYard's business to clarify their vision behind these 2 VMs, as both projects were started outside of EngineYard. This company is doing the Ruby community a favor by paying developers for working on these 2 projects, but the projects themselves would go on without EngineYard.

mark_l_watson 15y ago

As a Ruby developer, it is important for me to have options on deployment and also support for using large C/C++ libraries (e.g., Redland RDF) or large Java libraries (e.g., machine learning, Sesame RDF, etc., etc.) Great to have MRI C, Rubinius, and JRuby.