Hacker News Reader

Comment by stephenjudkins | Hacker News Reader

JRuby is pretty unique among non-reference language implementations in that it's often more performant, powerful, and stable than the standard Ruby implementations. It's been rock-solid for us recently, and integrates with Java surprisingly well.

I often think that the Ruby world would be a more productive place if the original implementation had leveraged the JVM.

View on HN

Erik DeBill did some interesting benchmarks lately that showed JRuby has a more linear performance overall when scaled up with heavier loads:

http://erik.debill.org/2011/02/03/ruby-performance-in-the-ra... http://erik.debill.org/2011/02/19/ruby-start-up-times

And the Torquebox team (Torquebox being a JRuby Rack app server using JBoss) also did some benchmarks and discovered (surprise, surprise) that Torquebox on JRuby significantly outperforms the alternatives on 1.9.2:

http://torquebox.org/news/2011/02/23/benchmarking-torquebox/ http://torquebox.org/news/2011/03/14/benchmarking-torquebox-...

(Disclaimer: Of course, benchmarks aren't authority figures so it's always worth running them for yourself..)

Just a nitpick, I see no comparison against 1.9.2 there in those Benchmarks. It is either REE or MRI 1.8.7.

One of the nicest things about JRuby (apart from performance and stability) is that you get easy access to all the wonderful Java libraries out there, which you can use with Ruby style syntax. These are often far higher quality than the Ruby equivalent, if that Ruby equivalent exists in the first place.

I've heard this argument a few times. As someone that's not new to Ruby but hasn't touched Java, can you elaborate as to what these awesome Java libraries are?

Lucene and the Java Topology Suite are libs we use that were unparalleled in completeness for our problem domain.

There's basically a library for everything. Creating or rendering PDFs? Several choices. Converting document formats? Choose the one with the license you like the most. Extracting data? Any format you want.

Then there's algorithms, support for just about any protocol under the sun. And the Java standard library is surprisingly complete as well - what you need might even be installed with your JVM.

Try googling for a Java library next time you think of something you want to do.

Our app sells to the finance vertical, so we deliver a lot of data in Excel. There is a really great project called Apache POI that does just what we need. Yes, there is also the Ruby spreadsheet gem, but while the gem itself works fine most of the time, the underlying reverse-engineering of the BIFF8 (Excel 97-2000) format is sketchy at best. Spreadsheets generated with the spreadsheet gem don't behave as expected in Excel. For example, if you click the '%' format button, you get an error message. This ends up making our product look unpolished.

This kind of turned in to a spreadsheet gem rant, but if you step back, it's typical of a greater problem. The Ruby community is relatively small when compared with the Java community. It's also significantly less "enterprisey". This means that you'll see a lot of effort put in to things that developers like -- clever libraries, syntactic "sugar", etc -- but you're less likely to see mature libraries like Apache POI. Who the hell wants to sit around and figure out BIFF8, anyway? A lot of the enterprise stuff just isn't fun, but there are plenty of Java devs who get paid to do it for their day jobs.

By using JRuby, you can benefit from both worlds.

remember though that the jvm in '95 was not even close to what it is now (and as a 'better perl' it would have made you cringe for the startup times)

That's been my experience; when testing both Mizuno (Jetty for Rack applications) and Unicorn under massively concurrent load, Unicorn tends to hit a point where it just stops responding, whereas Mizuno slows down, but handles every request successfully.

    ... if the original implementation had leveraged the JVM

I think that's a horrible idea. The JVM is an awful platform for any kind of language research & development, unless the type-system of that language is basically the same as in Java. I'm actually pretty upset that they've taken continuations out from 1.9 - most likely JRuby bares some blame.

Not to mention I would prefer to keep Oracle(TM) tainted stuff out of my lawn, as at this point I consider Mono/.NET to be more safe than Java.

Despite all that, JRuby does an absolutely bang-up job of working around the JVM's limitations where it can. As far as I know, it was the first language implementation anywhere on the JVM to allow forking, for instance.

True, but forking is also something which most languages running on top of Posix can do, that's not saying much.

What I really want and what is needed - a reference implementation written in 80% Ruby (or more). That's like Rubinius or Pypy, but adoption isn't great even though these virtual machines have shown better performance than the reference implementation for computational-heavy tasks.

And adoption isn't great because remarkable libraries written in native code won't run reliably or at all on top of them (e.g. Python's Scipy).

And JRuby shares the same problem, although it has the advantage of being able to use JVM-alternatives. But then you're stepping out of the Ruby ecosystem, which makes it a fork.

And to get back to "JRuby as reference implementation" ... it would be an even greater pain in the ass for alternative implementations, because C is more portable than Java.

Oh, absolutely. I'm not saying it's perfect, by any means - just that the JRuby team have pulled off an astounding job to get it as good as it is, given the limits of the JVM.

Also, native libraries are becoming less of a problem now that libffi has a bit of momentum.

This would make sense for web apps. For (presumably) many people, ruby still is mostly a sysadmin scripting language. In that case, shorter startup times are often more important than runtime performance. I personally love ruby but I wouldn't want to use it (or any dynamically typed language) for anything bigger.

Reply on news.ycombinator.com