I've seen several blogs and comments in news stories recently that boil down to the observation that programmers gravitate either to Python or Ruby for scripting, but not both. I guess I'm the exception that proves the rule: I've done Web templating projects using Python, and Web site projects using Ruby on Rails. For that matter, I've also done Web site projects in plain HTML, Perl, classic ASP and ASP.NET.
In my lab test of Rails IDEs I covered 9, count 'em 9 products. What was I thinking? I can't believe I did that. It was way more work than I'd planned on.
I started out proposing a review of Ruby in Steel Developer 1.2 on the strength of its unique Visual Rails Workbench, but reviewing that by itself didn't make sense to me. Then I thought I'd review Ruby in Steel against other Rails IDEs, but there turned out to be quite a few of those. And then I realized that I was leaving out TextMate and its clones. So, like Topsy, this review "just grow'd." I drew the line at editors that only know about Ruby and lack any Rails-specific features, but as I mentioned in the introduction to the article, you can make those work as well.
In Eric Knorr's Editor's Blog this week, he mentions the claims that Ruby on Rails scales poorly and lacks a security model. As far as I'm concerned, if good scaling and low latency are critical to your site, perhaps Rails isn't the right technology for you. On the other hand, Rails might be one of the fastest ways to develop a prototype site that you can throw away later. I wonder whether Twitter was supposed to be a throwaway prototype. But if that's the case, why haven't they rewritten the Twitter service so that it'll scale better?
Speaking of Ruby and scaling, Tim Bray knowingly used a naive Ruby script as the strawman benchmark for his Wide Finder 2 project. 78 lines of Ruby code analyzed 45 GB of Web logs in 25 hours. The strawman used only one of 32 possible hardware threads. If you look at the project results so far, you'll see scripts in Python, C++, Perl, Scala, Fan, Java, Groovy, OCaml, and gmake+sh+awk+C. The current champion is written in OCaml, a dialect of ML, and runs in 5 minutes using 31 worker threads.
Some of the speed difference certainly has to do with algorithms and threading. But some of the speed difference probably has to do with the slowness of the Ruby interpreter and libraries. If 5 minutes is roughly the I/O-bound time for this task using 31 worker threads, then a naive script running in one thread shouldn't take more than 160 minutes, or 2.67 hours. There's another factor of 9 to account for: is that because of Ruby?
Caveat coder.