Not intending to start a flamewar with VM/Intepreter implementations, BUT I have to agree with the article.
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.
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.
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.
* JVM here refers to Sun's JVM implementation, not the spec. JRockit is pretty good as well.
I don't think it's "having to know what to set it to up front" - its more experimentation and seeing what has the best performance. Too big heap and poor code, you might end up having really, really long GC pauses. Too small heap and you'll be out of heap space.
I like it as there's only so much physical memory on a server, and there's only so much virtual memory a kernel can provide. Swapping is not a good idea if you're looking into performance, and hence limiting the heap size can turn out to be a good strategy to ensure that your application does perform within expected boundries.
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.
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.
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 double the size of the Ruby community" - that's pretty incredible.
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.
I would have agreed with you on "Rails sucks to deploy" two years ago, when I started working with it, but the ecosystem is much, much better now. I don't use Passenger in production (no real benefit to a single-app developer whose app already works with Mongrel) so I won't comment on it, but Capistrano is mature to the point where deployment to a VPS is very, very painless.
You should see how much fun the deploy procedure is at my day job (Big Freaking Java Enterprise App) compared to "cap _1.4.2_ deploy".
As it happens I am looking at a stack of evaluations for the talk I gave internally about GAE, which included redoing an internal app on it. "Deployment is a non-issue" was not my experience. It is documented in the traditional Rails manner: as comments on blog posts, most of them out of date. It includes a lot of steps which are transparently bandaids over broken, like "Freeze Rails then delete the ActiveRecord gem to save on files because GAE has a hard limit on how many you can put in a WAR." It... bugger, meeting, will complete this thought later.
Other things not working on GAE, at least in my limited experience:
1) There is no way to run the console, period, which is a nuisance to my typical development style.
2) There appears to be no good way to do testing, which is a showstopper for many Rails developers. (I don't do TDD personally so not a big deal for me.)
3) Warble (wonderful software, don't get me wrong) has some performance issues, at least on this computer. (30 seconds to change one line in one file.) That wouldn't be a problem except...
4) ... I can't get GAE to operate locally with Rails, which means development has to be done by edit, deploy, edit, deploy, edit, deploy, which combines all the development speed of Big Freaking Java Enterprise Apps with the rich your-IDE-will-spot-typos-for-you power of Ruby. (/sarcasm)
5) You can't use ActiveRecord on GAE, which sounds like a nuisance until you realize how much of Rails magic depends on ActiveRecord being there. Validations, for example. (This was a major GOTCHA! for us.) I hear this will be mooted with Rails 3.0, which allows DataMapper (which will support Google's data store) to be dropped in in place of AR, but it is one of the major issues making me tell my bosses "The exploratory app was a big success, but the platform is not ready for us to take it to production yet, even though you have one production-ready app sitting in front of you."
Once you're at the capistrano level, deployment is a different game.. I'm talking about relatively small projects (I wouldn't deploy a big project on GAE anyway, if only to avoid the lock-in to Google)
I totally agree on most of issues you raise (once GAE Rails would work locally, console, testing etc could be resolved I suppose) - I would definitely not build any size Rails project for GAE right now. But if Rails community would put some work into that, I think it might be a great rapid dev/deploy/scale solution.
GAE is a pain in the ass regardless of the language. The only way it helps you scale (that can't be easily replicated) is the use of bigtable which has nothing to do with the language.
Not to take away from the discussion, but is anyone else attending eRubyCon (http://erubycon.com/) that Charles mentions in this article. Would be nice to meet and put faces on a few fellow HN'ers.
As someone who has spent a lot of time in those "lumbering" organizations, I tend to agree.
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.
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.
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.
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.
the various full stack rubies are cute, but if i don't have grown up concurrency then i'm not interested.
the various full stack rubies are cute, but if i don't have grown up concurrency then i'm not interested.
A place for everything. Ruby's weak threading is a shame, but doesn't keep Ruby/Rails from being an exceptionally productive way to build and deploy small/medium web applications, and to bootstrap large web applications.
Don't call Ruby "bad" because it's worse than Scala at Scala's strongest points.
you had better get serious about staking out your turf on the jvm
Also, isn't that the whole point of this article? A lot of Rubyists are doing this right now.
you're entitled to the downvotes, but I had hoped that they might be accompanied by a reply or two.
without that i'm left wondering if the disagreement/disapproval comes from ruby advocates with no facts to back their arguments or people who think that underendowed "office space" jokes are a valid retort for ruby fans with no facts to back their arguements.
I guesss maybe I do have a case of the Mondays, but you have undergraduate class project garbage collection and worse threads. Go charge $300 dollars a seat for your motivational ruby seminar or something. Scrum's at 11am.
If you were looking for replies, you might want to consider re-phrasing the way that you comment. A good way to engeder goodwill from others is to start off by talking about them, and not about yourself. Compare "If you were looking for replies," (starting to talk about what you want) vs "Scala is a better language than Ruby anyways." (which is an automatic trollish statement that puts your intended audience on the defensive right from the beginning)
Now, first of all, it's entirely possible that the Ruby community as a whole doesn't care about getting into the enterprise. I don't pretend to speak for the whole community, and obviously (via the article), some do. Competing on the JVM may not be the best way to promote the language as a whole. As you've said, the space is getting crowded, and if Ruby bets its cards on being the dynamic language of choice for the JVM, and then misses its target, how would that look? I won't deny that JRuby is an awesome thing, as I personally would like to see Ruby used (almost) everywhere. However, it's not as if, say, PHP gets maligned because it's not 'enterprisy' enough. It does for totally different reasons, and well-deserved ones at that. But the language is doing quite well without being able to be run on the JVM.
As far as concurrency and garbage collection go, I think it's hardly fair to judge all of Ruby on 1.8.7. YARV holds quite a bit of promise, and just goes to show how with just a little bit of care, Ruby can be made to be on par with every other language out there. See the link below for the comparison between 1.9 and 1.8. Now, in a pragmatic sense, this doesn't affect things _right now_, but they do change the near future quite a bit. So yes, Ruby's concurrency and gc may not be the best, but it's not as if there's no improvement or work being done.
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.
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.
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.
* JVM here refers to Sun's JVM implementation, not the spec. JRockit is pretty good as well.