The future of Ruby is....Java?
blog.headius.com
blog.headius.com
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.
Oh that has always irritated me, and others - having to know what to set it to up front - interesting that you like it?
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.
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).
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.
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.
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."
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.
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.
the various full stack rubies are cute, but if i don't have grown up concurrency then i'm not interested.
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.
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.
http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...
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.