5 ms·

A lot of folks in the Ruby community were hopeful that Rubinius would replace MRI to become Ruby 2.0. Looks like that's going to have to wait a little longer no

by compay 15y ago

A lot of folks in the Ruby community were hopeful that Rubinius would replace MRI to become Ruby 2.0. Looks like that's going to have to wait a little longer now.

Argorak 15y ago
It will most likely never happen. Also, Rubinius still has to fully implement Ruby 1.9, so its not like you could just flip a switch. On a side-note, a lot of folks are also dreamers.
- compay 15y ago
  It's not like MRI 2.0 is right around the corner either. A lot of work will be needed to get 2.0 out the door - potentially years. That work could instead be applied to Rubinius, and the release schedule could end up being similar. If it's "just a dream," it's largely for human reasons rather than technical ones.
  - Argorak 15y ago
    There are huge technological reasons as well. MRI is included in OS X, some Linux distros and even embedded in some systems. So there is a group of people that is interested in keeping exactly this system. Also, I have yet to see a purely technological decision of that magnitude, even in the world of compilers. I see Rubinius and JRuby winning the race, but I don't see any of them _replacing_ MRI.
    - compay 15y ago
      MacRuby also already comes with OS X - though it's currently still a private framework. By the time MRI 2.0 is ready to be released, the world will be a different place, MacRuby could by that time be the default Ruby on OS X. I understand there are good reasons to keep MRI around, but the idea of making Rubinius the future of core Ruby development is not an outlandish idea.
      - Argorak 15y ago
        But you have noticed that MacRuby is an MRI fork?
        compay 15y ago
        Yes. What's your point?
        Xylakant 15y ago
        Well, if rbx became the default implementation, lots of the effort that was invested in MacRuby would go stale. There's an incentive for the MacRuby people to keep investing into MRI since they can more easily adopt improvements from there. The benefit they get from taking code from MRI will diminish over time, but at least ATM I'd still expect it to be significant. (note: I'm not following MacRuby Development very closely at the moment.)
        lobster_johnson 15y ago
        While MacRuby is a fork, they have already replaced the VM with one that compiles to LLVM, which has been implemented in C++. They have also gutted things like String and Hash to use Objective-C's (or more precisely, Cocoa's) counterparts, and they have started using libdispatch (aka Grand Central Dispatch), Apple's open-source multicore tech. One of the big things about the new VM is that it eliminates the global interpreter lock, meaning MacRuby probably has much better parallelization than MRI. With the VM alone I think they are on their way to being their own Ruby implementation. All of this is a bit disappointing considering that they could have shared their improvements upstream and improved MRI performance for everyone, not just for Mac apps.
  - Xylakant 15y ago
    > If it's "just a dream," it's largely for human reasons rather than technical ones. That may be true, but don't we all preach that "People matter, not technologies" all the time? Nobody pretends that MRI 2.0 is round the corner, but rbx at the moment is not in a position to even replace MRI 1.9.2 (lack of windows support anyone?). Their current self-proclaimed status is 93% of the spec, so I don't think that stopping work on MRI and spending the next couple of month bringing RBX to the current MRI state is a valid alternative. Dropping MRI would also imply dropping the whole toolchain and all custom infrastructures based on MRI, lots of knowledge that people have with MRI would suddenly go worthless, etc... I seriously don't see that coming in the next couple of years.
- gnufied 15y ago
  For a lot of folks, rubinius has already replaced MRI. At least locally while developing. I am not sure, why you are saying "It will never happen".
  - Xylakant 15y ago
    > For a lot of folks, rubinius has already replaced MRI. At least locally while developing. This in itself certainly is a great achievement for the rubinius team and one to be proud of. However, I personally have to see a large production deployment. I consider rbx a serious alternative to mri, just as jruby is a serious alternative. I'll call it "replacement" once heroku starts using rbx and drops mri support. I don't see that happening in the next couple of years, there's just way too much investment behind mri for it to just go away.
    - regularfry 15y ago
      I think we're going to see a fork in the community, and I think heroku will end up supporting both MRI and rbx as equals.
      - Xylakant 15y ago
        I don't think we'll see a fork. There will be some gems that support rbx only and some that are MRI only and some that require jruby. However, seeing how things go with jruby I'd expect that most of the code stays runtime agnostic and people will use whatever runtime suits the current problem best. Given that there's a ruby spec now I imagine we'll end up pretty much where javascript is: Multiple runtimes that all support pretty much the same code. Or have a look at java or c, there's more than one jvm and with good reason as well as multiple c compilers that all produce working code :) And yes, I do see heroku supporting both MRI and rbx as equals, but my point was that that's not replacing.
  - Argorak 15y ago
    Thats the user perspective. I don't see the MRI team, which has built a whole tool-chain around developing MRI throwing away all that and to switch to a new platform. I like Rubinius very much, as I do with JRuby, I just don't see Rubinius replacing MRI. Thats what I meant by 'dreaming'. A non-realistic expectation that is not backed by any real events.
- rue 15y ago
  > Also, Rubinius still has to fully implement Ruby 1.9, so its not like you could just flip a switch. The only serious piece missing from 1.9 is the encoding support. There's a number of other relatively minor failures remaining, but those are simple enough to fix (and several people, contributors new and old, are doing so at this very moment). And the switch is -X19.
  - Argorak 15y ago
    I know that they are on a good track towards 1.9 support. My point still stands: they are not there yet. So, if you were an MRI developer: would you switch to an interpreter where would have to build that whole stuff from the last 3 years again?
    - regularfry 15y ago
      I can imagine a world where Rubinius never gets 1.9 encoding support, and declares it a non-goal. It's not that outlandish.
      - Xylakant 15y ago
        Which is something that I'd regard as a major setback. Here in Europe, a solid encoding support is pretty much a must-have for any up-to-date programming language. There's much more than utf-8 and not being able to handle that is a deal-breaker for me.
      - evanphx 15y ago
        It's being worked on right now and the infrastructure for it already in place. It's a goal.
      - msbarnett 15y ago
        Leaving aside the fact that encoding support is explicitly a goal, it would be an incredibly daft thing to do to decide that Rubinius was going to take a regressive, all-the-world-is-one-encoding point of view and break compatibility with much existing Ruby code.
lobster_johnson 15y ago
Considering that Rubinius is still considerably slower than MRI 1.9, that would be a big step backwards. Sure, considering that 2.0 will take a while to complete, one could put everyone to work on improving Rubinius' performance; but that would draw manpower away from non-performance work.
- compay 15y ago
  Rubinius has a different performance profile from MRI. It's considerably faster at some things and slower at others.
  - hello_moto 15y ago
    That would take even longer for serious production to switch to Rubinius. Especially when people have invested a lot in terms of learning how to boost MRI performance to the last drop.
    - compay 15y ago
      Yes, it would not be a painless change. But neither has the switch from 1.8 to 1.9 been pain-free. Just because it's hard doesn't mean it's not worth doing.
      - nirvdrum 15y ago
        Most of the large apps in production I'm aware of have just stuck with 1.8. It's stable and fast.
        compay 15y ago
        For most of my apps it's "fast enough" too. But I definitely wouldn't call it "fast."
        nirvdrum 15y ago
        Fair enough. But I meant "fast" relative to Ruby 1.9.2, not "fast" relative to anything else. The "require" issue aside, REE beats out 1.9.2 pretty handily in a lot of real world situations. I've seen 1.9.2 win in microbenchmarks, but I haven't actually seen it perform better on a real app yet. Obvious selection bias there, but the point really being there's no compelling reason to upgrade.
chollida1 15y ago
Could you summarize what benefits moving to Rubinius would buy Ruby developers? I'm an outsider looking in, so while I know what the MRI and Rubinius are, I don't know why I'd prefer to use Rubinius instead.
- compay 15y ago
  * Written mostly in Ruby * No GIL * JIT * Better garbage collector * Better debugging tools Unfortunately, Rubinius is not yet complete, so it's not a suitable MRI replacement for now.
  - chollida1 15y ago
    Thanks very much! Without the GIL what does that mean for extensions written in C. Would they need to be rewritten?
    - compay 15y ago
      Here's Evan Phoenix's answer from a while back: http://news.ycombinator.com/item?id=2265163 http://news.ycombinator.com/item?id=2265163
filmprog 15y ago
I feel that there are many contributions that Rubinius has made to the interpreter movement. a) the race for performance against other interpreters, b) the creation of an official "ruby spec" that defines what the ruby language is , and thus makes both the interpreters and the main language better and c) created a movement itself that has many different goals and target audiences. But I don't think that Evan, Brian, et al.'s goals have been to replace but rather further the movement of Ruby.

by compay 15y ago

A lot of folks in the Ruby community were hopeful that Rubinius would replace MRI to become Ruby 2.0. Looks like that's going to have to wait a little longer now.

Argorak 15y ago

It will most likely never happen. Also, Rubinius still has to fully implement Ruby 1.9, so its not like you could just flip a switch. On a side-note, a lot of folks are also dreamers.

compay 15y ago
It's not like MRI 2.0 is right around the corner either. A lot of work will be needed to get 2.0 out the door - potentially years. That work could instead be applied to Rubinius, and the release schedule could end up being similar. If it's "just a dream," it's largely for human reasons rather than technical ones.
- Argorak 15y ago
  There are huge technological reasons as well. MRI is included in OS X, some Linux distros and even embedded in some systems. So there is a group of people that is interested in keeping exactly this system. Also, I have yet to see a purely technological decision of that magnitude, even in the world of compilers. I see Rubinius and JRuby winning the race, but I don't see any of them _replacing_ MRI.
  - compay 15y ago
    MacRuby also already comes with OS X - though it's currently still a private framework. By the time MRI 2.0 is ready to be released, the world will be a different place, MacRuby could by that time be the default Ruby on OS X. I understand there are good reasons to keep MRI around, but the idea of making Rubinius the future of core Ruby development is not an outlandish idea.
    - Argorak 15y ago
      But you have noticed that MacRuby is an MRI fork?
      - compay 15y ago
        Yes. What's your point?
        Xylakant 15y ago
        Well, if rbx became the default implementation, lots of the effort that was invested in MacRuby would go stale. There's an incentive for the MacRuby people to keep investing into MRI since they can more easily adopt improvements from there. The benefit they get from taking code from MRI will diminish over time, but at least ATM I'd still expect it to be significant. (note: I'm not following MacRuby Development very closely at the moment.)
        lobster_johnson 15y ago
        While MacRuby is a fork, they have already replaced the VM with one that compiles to LLVM, which has been implemented in C++. They have also gutted things like String and Hash to use Objective-C's (or more precisely, Cocoa's) counterparts, and they have started using libdispatch (aka Grand Central Dispatch), Apple's open-source multicore tech. One of the big things about the new VM is that it eliminates the global interpreter lock, meaning MacRuby probably has much better parallelization than MRI. With the VM alone I think they are on their way to being their own Ruby implementation. All of this is a bit disappointing considering that they could have shared their improvements upstream and improved MRI performance for everyone, not just for Mac apps.
- Xylakant 15y ago
  > If it's "just a dream," it's largely for human reasons rather than technical ones. That may be true, but don't we all preach that "People matter, not technologies" all the time? Nobody pretends that MRI 2.0 is round the corner, but rbx at the moment is not in a position to even replace MRI 1.9.2 (lack of windows support anyone?). Their current self-proclaimed status is 93% of the spec, so I don't think that stopping work on MRI and spending the next couple of month bringing RBX to the current MRI state is a valid alternative. Dropping MRI would also imply dropping the whole toolchain and all custom infrastructures based on MRI, lots of knowledge that people have with MRI would suddenly go worthless, etc... I seriously don't see that coming in the next couple of years.
gnufied 15y ago
For a lot of folks, rubinius has already replaced MRI. At least locally while developing. I am not sure, why you are saying "It will never happen".
- Xylakant 15y ago
  > For a lot of folks, rubinius has already replaced MRI. At least locally while developing. This in itself certainly is a great achievement for the rubinius team and one to be proud of. However, I personally have to see a large production deployment. I consider rbx a serious alternative to mri, just as jruby is a serious alternative. I'll call it "replacement" once heroku starts using rbx and drops mri support. I don't see that happening in the next couple of years, there's just way too much investment behind mri for it to just go away.
  - regularfry 15y ago
    I think we're going to see a fork in the community, and I think heroku will end up supporting both MRI and rbx as equals.
    - Xylakant 15y ago
      I don't think we'll see a fork. There will be some gems that support rbx only and some that are MRI only and some that require jruby. However, seeing how things go with jruby I'd expect that most of the code stays runtime agnostic and people will use whatever runtime suits the current problem best. Given that there's a ruby spec now I imagine we'll end up pretty much where javascript is: Multiple runtimes that all support pretty much the same code. Or have a look at java or c, there's more than one jvm and with good reason as well as multiple c compilers that all produce working code :) And yes, I do see heroku supporting both MRI and rbx as equals, but my point was that that's not replacing.
- Argorak 15y ago
  Thats the user perspective. I don't see the MRI team, which has built a whole tool-chain around developing MRI throwing away all that and to switch to a new platform. I like Rubinius very much, as I do with JRuby, I just don't see Rubinius replacing MRI. Thats what I meant by 'dreaming'. A non-realistic expectation that is not backed by any real events.
rue 15y ago
> Also, Rubinius still has to fully implement Ruby 1.9, so its not like you could just flip a switch. The only serious piece missing from 1.9 is the encoding support. There's a number of other relatively minor failures remaining, but those are simple enough to fix (and several people, contributors new and old, are doing so at this very moment). And the switch is -X19.
- Argorak 15y ago
  I know that they are on a good track towards 1.9 support. My point still stands: they are not there yet. So, if you were an MRI developer: would you switch to an interpreter where would have to build that whole stuff from the last 3 years again?
  - regularfry 15y ago
    I can imagine a world where Rubinius never gets 1.9 encoding support, and declares it a non-goal. It's not that outlandish.
    - Xylakant 15y ago
      Which is something that I'd regard as a major setback. Here in Europe, a solid encoding support is pretty much a must-have for any up-to-date programming language. There's much more than utf-8 and not being able to handle that is a deal-breaker for me.
    - evanphx 15y ago
      It's being worked on right now and the infrastructure for it already in place. It's a goal.
    - msbarnett 15y ago
      Leaving aside the fact that encoding support is explicitly a goal, it would be an incredibly daft thing to do to decide that Rubinius was going to take a regressive, all-the-world-is-one-encoding point of view and break compatibility with much existing Ruby code.

lobster_johnson 15y ago

Considering that Rubinius is still considerably slower than MRI 1.9, that would be a big step backwards. Sure, considering that 2.0 will take a while to complete, one could put everyone to work on improving Rubinius' performance; but that would draw manpower away from non-performance work.

compay 15y ago
Rubinius has a different performance profile from MRI. It's considerably faster at some things and slower at others.
- hello_moto 15y ago
  That would take even longer for serious production to switch to Rubinius. Especially when people have invested a lot in terms of learning how to boost MRI performance to the last drop.
  - compay 15y ago
    Yes, it would not be a painless change. But neither has the switch from 1.8 to 1.9 been pain-free. Just because it's hard doesn't mean it's not worth doing.
    - nirvdrum 15y ago
      Most of the large apps in production I'm aware of have just stuck with 1.8. It's stable and fast.
      - compay 15y ago
        For most of my apps it's "fast enough" too. But I definitely wouldn't call it "fast."
        nirvdrum 15y ago
        Fair enough. But I meant "fast" relative to Ruby 1.9.2, not "fast" relative to anything else. The "require" issue aside, REE beats out 1.9.2 pretty handily in a lot of real world situations. I've seen 1.9.2 win in microbenchmarks, but I haven't actually seen it perform better on a real app yet. Obvious selection bias there, but the point really being there's no compelling reason to upgrade.

chollida1 15y ago

Could you summarize what benefits moving to Rubinius would buy Ruby developers? I'm an outsider looking in, so while I know what the MRI and Rubinius are, I don't know why I'd prefer to use Rubinius instead.

compay 15y ago
* Written mostly in Ruby * No GIL * JIT * Better garbage collector * Better debugging tools Unfortunately, Rubinius is not yet complete, so it's not a suitable MRI replacement for now.
- chollida1 15y ago
  Thanks very much! Without the GIL what does that mean for extensions written in C. Would they need to be rewritten?
  - compay 15y ago
    Here's Evan Phoenix's answer from a while back: http://news.ycombinator.com/item?id=2265163 http://news.ycombinator.com/item?id=2265163

filmprog 15y ago

I feel that there are many contributions that Rubinius has made to the interpreter movement. a) the race for performance against other interpreters, b) the creation of an official "ruby spec" that defines what the ruby language is , and thus makes both the interpreters and the main language better and c) created a movement itself that has many different goals and target audiences. But I don't think that Evan, Brian, et al.'s goals have been to replace but rather further the movement of Ruby.