4 ms·

Why Use Rubinius

73 points by bakkdoor 16y ago

defroost 16y ago
Another great read by Brian Ford. I mainly use MRI 1.9, but I have been experimenting with Rubinius of late. And it is getting better and better. Not only is the way Ruby in implemented cool, but the VM upon which languages like Fancy are being written is very exciting for the Ruby community.
thurn 16y ago
How is Rubinius going to tackle the GIL issue? They say they're working to get rid of it, but I'd assume that a sizable chunk of the Ruby standard library isn't thread safe, especially C extensions. I guess I'm just not sure how they plan to avoid the issues that Python faces: http://docs.python.org/faq/library#can-t-we-get-rid-of-the-global-interpreter-lock http://docs.python.org/faq/library#can-t-we-get-rid-of-the-g...
- kingkilr 16y ago
  That CPython faces. Neither Jython nor IronPython have GILs, and it should be much easier to remove PyPy's.
- wycats 16y ago
  A few points: a) The ruby standard library is written in Ruby and is actually surprisingly well-behaved from a threading perspective. The code is not super-pretty, but it uses appropriate locking strategies and has been well-tested in threaded environments. All three major implementations (JRuby, MRI and Rubinius) share the vast majority of the Ruby standard library, so if JRuby works, Rubinius will work. 2) For the part of MRI written in C (which Rubinius calls the "kernel"), Rubinius has reimplemented the entire thing mostly in Ruby with some primitives. Since they own that code, it is their responsibility to define its semantics when run in parallel. 3) Rubinius implements its locking classes (like Mutex and ConditionVariable, see https://github.com/evanphx/rubinius/blob/master/lib/thread.rb#L40 https://github.com/evanphx/rubinius/blob/master/lib/thread.r...) on top of its own low-level Channel implementation (see https://github.com/evanphx/rubinius/blob/master/kernel/bootstrap/channel.rb#L15 https://github.com/evanphx/rubinius/blob/master/kernel/boots...), which can be used to implement more sophisticated locking strategies. They have been working on this for a long time, and have been planning for it even longer.
  - riffraff 16y ago
    grandparent was probably thinking of how you avoid the GIL if existing extensions are written expecting to be used by a single thread. Since rubinius provides the same C-api ruby does (ignoring FFI for now) wouldn't all the accesses to external libraries need to be wrapped in a shared big lock?
    - evanphx 16y ago
      For the time being, we use a lock that has to be held to run methods defined in C extensions, a GEL (Global Extension Lock) if you will. We've got some other ideas to increase concurrency in extensions, but the crux is that yes, we have to perform some locking because people wrap thread unsafe libraries. Because Rubinius does not use the C-API to implement anything in the core, this doesn't impact general concurrency.
wheels 16y ago
I'll put forward a more blunt answer: because Rubinius is the only tenable way forward, long-term, for Ruby. MRI is a steaming pile. (Note: You're not allowed to disagree with this unless you're a C programmer that's spent some quality time with MRI's code.) It seriously shook my faith in Ruby the first time I had to dive into MRI's code: "Could someone who waxes poetic about elegance and fun in coding really produce something this fugly? Does Matz have any idea what he's talking about?" Rubinius has a sane design and is a pretty clean base to build a Ruby implementation with some staying power on. I basically see Rubinius as the rewrite that MRI was going to have to have at some point. That said, at present, I still use MRI. I try Rubinius every couple months to see how it's progressed performance-wise for the cases that I care about, and while it's not there yet, this seems to be mostly a matter of time.
- jshen 16y ago
  I'm all jruby all the time these days, and I couldn't be happier.
- steveklabnik 16y ago
  How do you feel about YARV? I mean, Matz has always been honest that he's not a compiler guy... That said, I think rbx is the way forward too.
- riffraff 16y ago
  my hopes for the future are in RBX but why would the ugliness of MRI (I assume you include yarv in it) make it untenable in the long term? There is a massive amount of bad code on the intertubes that has been around for decades, and I kind of hope we will not be programming in ruby when it's 40 years old.
isak2 16y ago
This is more "Why use Ruby" than "Why use Rubinius."
atambo 16y ago
Why not use http://jruby.org http://jruby.org?
- tptacek 16y ago
  C extensions are a very big reason why not; the pain of demand-starting JVMs is another minor reason.
  - atambo 16y ago
    I suppose it depends on what you're using ruby for. I use it for long running processes like rails apps so the jvm startup time really doesn't matter. And jruby has support for c extensions that use ffi.
    - tptacek 16y ago
      Nobody's saying not to use jruby. You asked a question, I gave one answer.
  - Confusion 16y ago
    The second is actually much less painful than people generally think. Jruby -e 'some code' only takes half a second on my machine, which is fast enough to not be a problem. The main slowness people experience has to do with loading gems, usually via rubygems. That is painfully slow, but does not have anything to do with JVM startup time.
    - tptacek 16y ago
      "jruby -e 1", cold start, just took 4 seconds for me. I use jruby interactively almost every day (it's extremely handy in penetration testing), and I'm pretty sure jruby is noticeably slower to start than MRI.
      - Confusion 16y ago
        It's definitely noticably slower, but 4 seconds per startup would make it unusable for me. However, since it's time jruby -e 1 real 0m0.514s user 0m0.510s sys 0m0.040s I find it acceptable (could it be the SSD in my laptop that makes such a large difference?). As http://jira.codehaus.org/browse/JRUBY-5181 http://jira.codehaus.org/browse/JRUBY-5181 shows, as soon as some gems come into the picture, actual startup times deteriorate rapidly.

73 points by bakkdoor 16y ago

Another great read by Brian Ford. I mainly use MRI 1.9, but I have been experimenting with Rubinius of late. And it is getting better and better. Not only is the way Ruby in implemented cool, but the VM upon which languages like Fancy are being written is very exciting for the Ruby community.

thurn 16y ago

How is Rubinius going to tackle the GIL issue? They say they're working to get rid of it, but I'd assume that a sizable chunk of the Ruby standard library isn't thread safe, especially C extensions. I guess I'm just not sure how they plan to avoid the issues that Python faces: http://docs.python.org/faq/library#can-t-we-get-rid-of-the-global-interpreter-lock http://docs.python.org/faq/library#can-t-we-get-rid-of-the-g...

kingkilr 16y ago
That CPython faces. Neither Jython nor IronPython have GILs, and it should be much easier to remove PyPy's.
wycats 16y ago
A few points: a) The ruby standard library is written in Ruby and is actually surprisingly well-behaved from a threading perspective. The code is not super-pretty, but it uses appropriate locking strategies and has been well-tested in threaded environments. All three major implementations (JRuby, MRI and Rubinius) share the vast majority of the Ruby standard library, so if JRuby works, Rubinius will work. 2) For the part of MRI written in C (which Rubinius calls the "kernel"), Rubinius has reimplemented the entire thing mostly in Ruby with some primitives. Since they own that code, it is their responsibility to define its semantics when run in parallel. 3) Rubinius implements its locking classes (like Mutex and ConditionVariable, see https://github.com/evanphx/rubinius/blob/master/lib/thread.rb#L40 https://github.com/evanphx/rubinius/blob/master/lib/thread.r...) on top of its own low-level Channel implementation (see https://github.com/evanphx/rubinius/blob/master/kernel/bootstrap/channel.rb#L15 https://github.com/evanphx/rubinius/blob/master/kernel/boots...), which can be used to implement more sophisticated locking strategies. They have been working on this for a long time, and have been planning for it even longer.
- riffraff 16y ago
  grandparent was probably thinking of how you avoid the GIL if existing extensions are written expecting to be used by a single thread. Since rubinius provides the same C-api ruby does (ignoring FFI for now) wouldn't all the accesses to external libraries need to be wrapped in a shared big lock?
  - evanphx 16y ago
    For the time being, we use a lock that has to be held to run methods defined in C extensions, a GEL (Global Extension Lock) if you will. We've got some other ideas to increase concurrency in extensions, but the crux is that yes, we have to perform some locking because people wrap thread unsafe libraries. Because Rubinius does not use the C-API to implement anything in the core, this doesn't impact general concurrency.

wheels 16y ago

I'll put forward a more blunt answer: because Rubinius is the only tenable way forward, long-term, for Ruby. MRI is a steaming pile. (Note: You're not allowed to disagree with this unless you're a C programmer that's spent some quality time with MRI's code.) It seriously shook my faith in Ruby the first time I had to dive into MRI's code: "Could someone who waxes poetic about elegance and fun in coding really produce something this fugly? Does Matz have any idea what he's talking about?" Rubinius has a sane design and is a pretty clean base to build a Ruby implementation with some staying power on. I basically see Rubinius as the rewrite that MRI was going to have to have at some point. That said, at present, I still use MRI. I try Rubinius every couple months to see how it's progressed performance-wise for the cases that I care about, and while it's not there yet, this seems to be mostly a matter of time.

jshen 16y ago
I'm all jruby all the time these days, and I couldn't be happier.
steveklabnik 16y ago
How do you feel about YARV? I mean, Matz has always been honest that he's not a compiler guy... That said, I think rbx is the way forward too.
riffraff 16y ago
my hopes for the future are in RBX but why would the ugliness of MRI (I assume you include yarv in it) make it untenable in the long term? There is a massive amount of bad code on the intertubes that has been around for decades, and I kind of hope we will not be programming in ruby when it's 40 years old.

isak2 16y ago

This is more "Why use Ruby" than "Why use Rubinius."

atambo 16y ago

Why not use http://jruby.org http://jruby.org?

tptacek 16y ago
C extensions are a very big reason why not; the pain of demand-starting JVMs is another minor reason.
- atambo 16y ago
  I suppose it depends on what you're using ruby for. I use it for long running processes like rails apps so the jvm startup time really doesn't matter. And jruby has support for c extensions that use ffi.
  - tptacek 16y ago
    Nobody's saying not to use jruby. You asked a question, I gave one answer.
- Confusion 16y ago
  The second is actually much less painful than people generally think. Jruby -e 'some code' only takes half a second on my machine, which is fast enough to not be a problem. The main slowness people experience has to do with loading gems, usually via rubygems. That is painfully slow, but does not have anything to do with JVM startup time.
  - tptacek 16y ago
    "jruby -e 1", cold start, just took 4 seconds for me. I use jruby interactively almost every day (it's extremely handy in penetration testing), and I'm pretty sure jruby is noticeably slower to start than MRI.
    - Confusion 16y ago
      It's definitely noticably slower, but 4 seconds per startup would make it unusable for me. However, since it's time jruby -e 1 real 0m0.514s user 0m0.510s sys 0m0.040s I find it acceptable (could it be the SSD in my laptop that makes such a large difference?). As http://jira.codehaus.org/browse/JRUBY-5181 http://jira.codehaus.org/browse/JRUBY-5181 shows, as soon as some gems come into the picture, actual startup times deteriorate rapidly.