JRuby and Ruby
I spent a lot of time at JAX last week in discussions about Ruby and Rails, both on stage and offline. A recurring theme was the Java community's reluctance to accept anything that doesn't run on the JVM. The arguments brought forward can be separated roughly into the following three categories:
- Legacy. People insist on being able to protect their existing investments, in terms of hardware, software, and skills. Being able to run Ruby as just another language on the JVM, essentially including the option to simply deliver byte code without ever talking about a change in the programming language, is perceived as a key requirement.
- Performance and Scalability. Scaling with processes instead of threads; having to manage a cluster of long-running processes; being forced to rely on Apache's features for load-balancing: there was general agreement that this is a lot worse than being able to rely on the existing Java infrastructure.
I don't necessarily agree with these criticisms. For one, I believe systems should be coupled much more loosely than by running them on the same VM and integrating them on the language level. I also think that in many cases, scaling with processes in a shared-nothing architecture scales perfectly well, and it also doesn't require any sophisticated infrastructure beyond a boilerplate Unix platform. I expect a lot of innovation to occur within the Ruby VM space, specifically around Rubinius. And lastly, I know from personal experience that in many cases the JVM and a fat app server sitting on top of it are used to serve a simple JSP/servlet application to a few dozen users, i.e. used in a scenario where Perl CGI would suffice.
But while I don't find these arguments convincing enough for many use cases, it's very hard to find arguments against running Ruby on the JVM. JRuby has reached a level of maturity that makes it a great choice even if you don't care about Java at all. As it runs Rails, I'm reasonably confident it will run basically any Ruby library I could care about -- except, of course, those that rely on a native library to deliver their features. But in this case, the vast ecosystem of Java libraries should outweigh this disadvantage easily.
So assuming you can deploy your Ruby application to a JVM platform without hassle, why wouldn't you?
I am far from experienced with this, but the one thing from a few releases ago for jruby was startup time for the jvm - all the class loading, etc. I think this has been an area of improvement for the jruby team.
Another reason could be better access to C libraries on the CRuby runtime. People have been working hard at making that a non-factor for JRuby as well, I know. But that often is resolved by reimplementing a C library in Java, which is not necessarily a desirable trend.
Mike “Fuzzy” Herrick has been using jruby/rails pretty heavily for many months now — he may have a good story to relate.
I don’t agree with you on this. In current Rails land, you’ll need a process instance for each expected, concurrent user. Even trivial Rails applications consume something along the lines of 50 MB per process, and nearly all of that is non-shareable private heap space (i.e. no .so’s).
So if you expect 100 concurrent users on your webpage, you’re looking at 5000 MB RAM. Of course, 100 truly concurrent users is not really a piece of cake, but compare this to Java, PHP (ugh), … you name it, where at least the memory footprint won’t be a problem at all.
And less memory consumption of course means more buffers and caches, which can easily reduce your CPU problems.
If you run Comet-style applications or web apps where you need to access services in the background, with an accordingly large increase in response time but no CPU usage, 100 concurrent users is quite normal.
Scaling with processes does have problems.