I think his point about performance was more that the rails developers were not taking significant steps to improve it. From what I understand, they are doing this for Ruby 2.0.
He definitely addresses the programmer time thing a lot, except from the perspective of code readability instead of keystrokes or whatever other metric you might use. Python is generally a much more readable language, and might make for more maintainable large scale systems because of it.
>From what I understand, they are doing this for Ruby 2.0.
In less than a year's time, you'll have so many choices to choose from. Ruby 1.9 is just one of the Ruby interpreters that you'll be able to pick from. There's also Rubinius (which is already outperforming MRI on so many benchmarks)
And you'll also be able to choose from JRuby and IronRuby. The way I see it, I think there's more work being done on improving Ruby's than Python's ecosystem.
Ruby people should be more candid about the performance situation, which is a catastraphuck. It is worth it, it will probably get better, and raw performance isn't that important for I/O bound apps, but Ruby is noticeably slower than pretty much all its competitors.
People make this claim all the time but I never hear anyone talk about actual examples where they were bitten by this.
People especially like to harp on the speed of ruby as a knock on ruby on rails. However I have not once run into a real life situation where the performance problem was directly related to the raw performance of Ruby. I have though run into plenty of performance problems:
* At Odeo (RoR circa 2005) we had plenty of problems with memory leaks in our FCGI (this was 2005!) processes and in feed_tools (well known to be slow)
* At my next company we quickly ran into situations where pages were slow to load due to the sheer number of database calls. When I started doing web apps I can remember never having more than three queries behind any given page. Some of our pages were doing 500 queries. This was easily fixed but Rails definitely tempts you to put up scaffolding which you then have to rework once it starts getting real use. In my experience this is a good thing. I'm twice as likely to throw away the scaffolding than I am to have to rewrite it.
* Twitter, which is the poster child for RoR scaling issues, actually actually has had almost all their problems on the backend, having to rapidly change their database and message queue architectures and deal with flaky service providers (AOL and phone companies). Again nothing to do with the architecture they launched with.
So, in the lab Ruby is a slow language, but in the real world how is this biting people?
Like I said earlier, our app parses with racc, does cryptography, and a fair bit of analysis. It is not heavily database dependent. Most of our I/O is memcached. I assert without evidence that Ruby's performance deficits have in fact bit us.
He definitely addresses the programmer time thing a lot, except from the perspective of code readability instead of keystrokes or whatever other metric you might use. Python is generally a much more readable language, and might make for more maintainable large scale systems because of it.