Not intending to start a flamewar with VM/Intepreter implementations, BUT I have to agree with the article.<p>When I was evaluating on platforms for a rewrite of xp-dev.com, I did seriously consider using RoR with JRuby, but there was some parts missing here and there (including some bugs) that it was just not worth the risk for the scale of the project.<p>I ended up going back to a Java web framework, thinking, I'll keep a close eye on JRuby and see if it can be used in future projects.<p>The JVM is an excellent VM - things like having the ability to set heap sizes, JMX and all the readily available sugar that comes from it is well worth trying to support as many languages into it, and for that reason, Ruby needs the JVM. Re-implementing things like JIT, GC is just not worth the trouble. Ruby hackers can actually focus on real, hard productive features and essential bug fixes which would be a better use of their precious time.<p>* JVM here refers to Sun's JVM implementation, not the spec. JRockit is pretty good as well.
If Charles really believes this then he needs to assign a bit more priority to some of bugs / feature requests that revolve around java integration. I wouldn't mind using JRuby to replace various java oriented tasks but the lack of various features such as full support for annotations makes it impossible.<p>He's definitely right about one thing though - JRuby has to some extent missed the bus here - Groovy now does just about everything I need and it would now be a big sell to win me back to using JRuby (which was not true 1 or 2 years ago).
I'm honestly really thrilled with all the choices on the JVM; not just JRuby, but Java, Clojure, Groovy, Scala, Fan... and they all play together incredibly nicely. It's an amazing productivity boost to be able to use a dynamic language (like Ruby or Groovy) to handle all the business logic and glue code, while at the same time being able to take advantage of the speed of pure Java when you need it.
Except that almost all these comments seem to assume a long-running / web process.<p>Start-up times and memory requirements for the JVM are just horrendous; I can't write a serious command-line tool in Java because of these constraints. Even Scala has a compiler-tool which runs as a background task (fsc) because of this.
"If we can leverage JRuby to grab 1-2% of the Java market, we'll <i>double</i> the size of the Ruby community" - that's pretty incredible.<p>IMHO it could be smart of the community to put some effort into getting JRuby on Rails working smoothly on Google App Engine. GAE makes deployment and scaling, traditionally RoR's weaker points (though much improved since Passenger) almost a non-issue.
As someone who has spent a lot of time in those "lumbering" organizations, I tend to agree.<p>While it isn't unreasonable to expect professionals to learn multiple deployment scenarios, the sad truth is that it can be hard to arrange to have such professionals.<p>Expecting someone who's career has revolved around JBoss/WebLogic/Tomcat/whatever, to come to grips with the vagaries of mongrel clusters is a recipe for failure. Not only does it mean learning something new, something they may regard as a "toy", it is a solution which exists outside of their domain, i.e., a threat.<p>That doesn't mean it can't be done, but it does mean being able to say "it's a war file" is a huge and important lever.
Not to take away from the discussion, but is anyone else attending eRubyCon (<a href="http://erubycon.com/" rel="nofollow">http://erubycon.com/</a>) that Charles mentions in this article. Would be nice to meet and put faces on a few fellow HN'ers.
scala is a better language than ruby anyways. if you rubyists want to promote your language you had better get serious about staking out your turf on the jvm, which is (i'm sorry to say) the only non-microsoft place where the enterprise can find serious concurrency and gc.<p>the various full stack rubies are cute, but if i don't have grown up concurrency then i'm not interested.