The Great Ruby Shootout (July 2010)
programmingzen.com
The Great Ruby Shootout (July 2010)
1–10 of 45 posts
Re: The Great Ruby Shootout (July 2010)
#2[deleted]
Re: The Great Ruby Shootout (July 2010)
#3JRuby would be the future if the startup times weren't so horrendous. It makes it very unpalatable for scripting. Nailgun is not robust enough. I have a feeling this is going to be more of a JVM problem than something Nutter and team is going to tackle. So is the future Rubinius and JRuby?
Re: The Great Ruby Shootout (July 2010)
#4It will be interesting to see what sort of difference Java 7 makes for JRuby.
Re: The Great Ruby Shootout (July 2010)
#5JRuby would be the future if the startup times weren't so horrendous. It makes it very unpalatable for scripting. Nailgun is not robust enough. I have a feeling this is going to be more of a JVM problem than something Nutter and team is going to tackle. So is the future Rubinius and JRuby?
For scripting, that's definitely a problem. But it's not a big deal for long-running processes (e.g. a web application server). But Ruby definitely benefits from both: a fast Ruby with ~zero startup time, and a fast Ruby on the JVM.
3 years ago, Ruby implementation problems became the hot topic at Ruby conferences. Ruby was a beautiful language with an ugly implementation. It's great to see that the community has executed on this concern.
Re: The Great Ruby Shootout (July 2010)
#6JRuby would be the future if the startup times weren't so horrendous. It makes it very unpalatable for scripting. Nailgun is not robust enough. I have a feeling this is going to be more of a JVM problem than something Nutter and team is going to tackle. So is the future Rubinius and JRuby?
The tradeoff is that you get a much more stable runtime, true multithreading, and the ability to play ball with everything in the Java ecosystem.
Sure, it takes longer to start up, but we're talking a few seconds here, which is nothing for a long-running webapp. Plus, the JVM is rock-solid, has very predictable memory usage, and also has tons of monitoring infrastructure to bring to bear against problems.
Yeah, I'm a fan.
Re: The Great Ruby Shootout (July 2010)
#7JRuby would be the future if the startup times weren't so horrendous. It makes it very unpalatable for scripting. Nailgun is not robust enough. I have a feeling this is going to be more of a JVM problem than something Nutter and team is going to tackle. So is the future Rubinius and JRuby?
I'm much, much more concerned about the memory usage of JRuby than the startup times. For toss-off scripts I can keep using MRI.
I've read that JRuby memory usage scales better than MRI though, so you pay a higher cost upfront but can actually accommodate more workers on the same hardware. I haven't gotten far enough in my exploration of JRuby to see if this is the case in my own apps.
Hats off to all the devs working on bringing us a better Ruby runtime. I realize it's a lot of work.
Re: The Great Ruby Shootout (July 2010)
#8Why no IronRuby test on Windows? Understand, I'm no fan of M$, but it seems very odd to run the IronRuby test on Mono, then omit running IronRuby on the "native" .NET environment.
Re: The Great Ruby Shootout (July 2010)
#9Too bad there's no MacRuby, which is probably the fastest ruby interpreter (though it only runs on OS X).
Re: The Great Ruby Shootout (July 2010)
#10Too bad there's no MacRuby, which is probably the fastest ruby interpreter (though it only runs on OS X).
It's right there in the first paragraph of the article: http://programmingzen.com/2010/05/16/benchmarking-macruby-0-...