

Why Use Rubinius - bakkdoor
http://rubini.us/2011/02/25/why-use-rubinius/

======
wheels
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
I'm all jruby all the time these days, and I couldn't be happier.

------
thurn
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...](http://docs.python.org/faq/library#can-t-we-get-rid-of-the-global-
interpreter-lock)

~~~
wycats
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...](https://github.com/evanphx/rubinius/blob/master/lib/thread.rb#L40))
on top of its own low-level Channel implementation (see
[https://github.com/evanphx/rubinius/blob/master/kernel/boots...](https://github.com/evanphx/rubinius/blob/master/kernel/bootstrap/channel.rb#L15)),
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
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
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.

------
defroost
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
Why not use <http://jruby.org>?

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

~~~
atambo
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
Nobody's saying not to use jruby. You asked a question, I gave one answer.

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

