
Rails on Rubinius - lurkage
http://blog.fallingsnow.net/2008/05/17/rails-on-rubinius/
======
goodkarma
Haven't tried Rubinius yet myself, but being able to run rails on it is a huge
milestone.

Some of the benefits of Rubinius, from what I've heard so far:

\- uses modern techniques to decrease memory usage and increase throughput

\- less memory change per additional mongrel instance

\- capability for precompiled code (similar to java .jar files)

\- better performance

\- better error reporting

\- profiling has less impact on performance

I think it could totally change the rails landscape as we know it.

<http://rubyconf2007.confreaks.com/d2t1p3_rubinius.html>

[http://www.slideshare.net/evanphx/rubinius-improving-the-
rai...](http://www.slideshare.net/evanphx/rubinius-improving-the-rails-
ecosystem/)

------
KirinDave
This is exciting. The #1 thing holding back Ruby right now is its aging and
leaky implementation. I'd say half my debugging time spent on ruby ends with,
"Oh, the implementation of ruby has a bug."

This is not to say the Ruby guys aren't smart and don't work hard, but you
can't squeeze blood from a stone.

~~~
jamesbritt
Have you looked at Ruby 1.9?

Or JRuby?

I'm stoked about Rubinious, but for day-to-day, you-can-use-it now excitement
my money's on JRuby.

~~~
KirinDave
I have, and I have. I just want there to be more competition amongst these
alternative implementations.

------
jamesbritt
The blog post doesn't make it clear: Is ActiveRecord running under Rubinious?

------
dmix
Could someone explain what this is to a Rails guy?

~~~
maximilian
So, you know how like Rails runs on Ruby, which is kinda slow. As you may or
may not know, Ruby isn't compiled into any sort of machine code, or even
bytecode. It is compiled down into a tree-representation (like all languages i
think), but instead of taking this tree representation into bytecode or native
machine code, they just leave it. This makes ruby extra slow and hard to
optimize. Rubinus (as far as I know) takes the tree and makes bytecode which
is then executed on a VM. This should make it _much_ faster.

~~~
randy
Although this is what should happen, it doesn't quite seem to be the case.
Pretty much every other ruby implementation destroys Rubinius in terms of
performance. It's also worthwhile to note that 1.9/YARV, which is bytecoded,
destroys every other ruby implementation and should actually be a major boost
to Rails once the compatibility issues are worked out (Matz released 1.9
during Christmas of 2007, but it's just the developer version). You can see
benchmarks here:

[http://antoniocangiano.com/2007/02/19/ruby-
implementations-s...](http://antoniocangiano.com/2007/02/19/ruby-
implementations-shootout-ruby-vs-yarv-vs-jruby-vs-gardens-point-ruby-net-vs-
rubinius-vs-cardinal/)

You can also see how 1.9 fares against 1.86 directly in the code shootout:

[http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?t...](http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=yarv)

Rubinius seems to offer some nice support in terms of running reliable ruby
(<http://en.wikipedia.org/wiki/Rubinius>), but in terms of performance and
actual usability, it has a long way to go.

~~~
kingkongrevenge
Parrot ftw. Why should there be so much redundant effort on so many dynamic
language VMs? They will all run best on Parrot soon enough. The languages will
easily share libraries, too.

~~~
jamesbritt
Or Ruby 1.9 for FTW.sooner, if you are mainly concerned with Ruby.

Or JRuby, FTW.now, as amazing progress is made daily, and I expect that
interaction of libraries from other J* languages will be all part of the JVM
wonderland.

