Why Use Rubinius

73 points by bakkdoor 15 years ago | 20 comments

wheels 15 years 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 15 years ago | |

I'm all jruby all the time these days, and I couldn't be happier.

steveklabnik 15 years 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 15 years 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.

thurn 15 years 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-g...

wycats 15 years 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.r...) on top of its own low-level Channel implementation (see 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 15 years 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?

kingkilr 15 years ago | |

That CPython faces. Neither Jython nor IronPython have GILs, and it should be much easier to remove PyPy's.

defroost 15 years 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.

atambo 15 years ago |

Why not use http://jruby.org?

tptacek 15 years ago | |

C extensions are a very big reason why not; the pain of demand-starting JVMs is another minor reason.

atambo 15 years 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.

Confusion 15 years 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.

isak2 15 years ago |

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