Rails on Rubinius | Hacker News Reader

Rails on Rubinius

blog.fallingsnow.net

16 pointslurkage11 comments

Open articleView on HN

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...

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.

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.

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

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

Could someone explain what this is to a Rails guy?

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.

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...

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...

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.

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.

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.

Arg, how can you be a rails guy if you need this explained?

Reply on news.ycombinator.com