6 ms·

Rubinius 2.0 Preview Release

100 points by ichverstehe 15y ago

andrewvc 15y ago
Awesome, the great thing about rubinius is playing around with the internals, since they're mostly written in ruby. The C++ core is quite tiny actually.
senthilnayagam 15y ago
muti-core support is interesting, installing now on my mbp
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.
  - 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.
MartinMond 15y ago
Is running Rails on Rubinius 2.0 still slower than on MRI 1.9.2? I hope not, but I need MRI 1.9.2 as a baseline (and yes, MRI is itself horribly slow)
- headius 15y ago
  Only one way to find out :)
fijal 15y ago
According to my very unscientific measurements (I didn't bother looking which files are potentially auto generated), I got: 182kloc of C (.c files) 110kloc of c++ (.h + .cpp files) 558kloc of ruby (.rb files) That puts C/C++ at roughly 40% of total. Unless proven otherwise I would say "ruby written in ruby" is a bit untrue.
- headius 15y ago
  Your numbers are odd. I would discount the .c code. Rubinius's native code (excluding third-party code) is largely C++, so better to focus on .cpp and .hpp files. The .rb count is way higher than what I got. The line counts I got (on master, not hydra): vm / {cpp,hpp}: 162kloc kernel / rb: 31kloc lib / rb: 145kloc Oddly enough the total ratio is roughly what you came up with, but I'm not sure where your numbers came from. It's worth noting that the density of .rb source is considerably higher than that of .cpp source; a few lines of .rb can do what might take dozens or hundreds of lines of .cpp. I wouldn't fault them based on LOC; Rubinius is still implemented more in Ruby than any other implementation out there. Let's say .rb is conservatively worth 10LOC of C++. That puts them at more like 10% "not Ruby", going by the amount of work they get done in each language. Even if you only consider kernel / rb versus vm / {cpp,hpp}, the 10X ratio means they're less than 1/3 "not Ruby". That's pretty good.
  - fijal 15y ago
    I just counted everything including stdlib and whatnot (all that comes in the checkout). "Rubinius is still implemented more in Ruby than any other implementation out there." well that's probably true, but not really useful. If all ruby implementations had 0 lines of Ruby and Rubinius 1 would you call it "mostly written in ruby"? 10X on LOC count is bogus, just because it's a single number. It does depend on what you do, it might end up being that, being more or being less, essentially [citation needed]. Anyway, even assuming this odd coefficient, I wouldn't say 1/3 "not Ruby" is "pretty good", although "pretty good" is not a precisely defined term, so we're free to agree to disagree on that. Given the same assumptions you can say CPython is written mostly in Python (10x Python-vs-C, including all the library code).

100 points by ichverstehe 15y ago

Awesome, the great thing about rubinius is playing around with the internals, since they're mostly written in ruby. The C++ core is quite tiny actually.

senthilnayagam 15y ago

muti-core support is interesting, installing now on my mbp

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

MartinMond 15y ago

Is running Rails on Rubinius 2.0 still slower than on MRI 1.9.2? I hope not, but I need MRI 1.9.2 as a baseline (and yes, MRI is itself horribly slow)

headius 15y ago
Only one way to find out :)

fijal 15y ago

According to my very unscientific measurements (I didn't bother looking which files are potentially auto generated), I got: 182kloc of C (.c files) 110kloc of c++ (.h + .cpp files) 558kloc of ruby (.rb files) That puts C/C++ at roughly 40% of total. Unless proven otherwise I would say "ruby written in ruby" is a bit untrue.

headius 15y ago
Your numbers are odd. I would discount the .c code. Rubinius's native code (excluding third-party code) is largely C++, so better to focus on .cpp and .hpp files. The .rb count is way higher than what I got. The line counts I got (on master, not hydra): vm / {cpp,hpp}: 162kloc kernel / rb: 31kloc lib / rb: 145kloc Oddly enough the total ratio is roughly what you came up with, but I'm not sure where your numbers came from. It's worth noting that the density of .rb source is considerably higher than that of .cpp source; a few lines of .rb can do what might take dozens or hundreds of lines of .cpp. I wouldn't fault them based on LOC; Rubinius is still implemented more in Ruby than any other implementation out there. Let's say .rb is conservatively worth 10LOC of C++. That puts them at more like 10% "not Ruby", going by the amount of work they get done in each language. Even if you only consider kernel / rb versus vm / {cpp,hpp}, the 10X ratio means they're less than 1/3 "not Ruby". That's pretty good.
- fijal 15y ago
  I just counted everything including stdlib and whatnot (all that comes in the checkout). "Rubinius is still implemented more in Ruby than any other implementation out there." well that's probably true, but not really useful. If all ruby implementations had 0 lines of Ruby and Rubinius 1 would you call it "mostly written in ruby"? 10X on LOC count is bogus, just because it's a single number. It does depend on what you do, it might end up being that, being more or being less, essentially [citation needed]. Anyway, even assuming this odd coefficient, I wouldn't say 1/3 "not Ruby" is "pretty good", although "pretty good" is not a precisely defined term, so we're free to agree to disagree on that. Given the same assumptions you can say CPython is written mostly in Python (10x Python-vs-C, including all the library code).