Why Ruby/Rails speed doesn't matter?

I wrote this as a response, but it's awaiting moderation:

I think this article is pretty irresponsible. Your making some weak excuses for Ruby's poor performance that, frankly, speaks more about your laziness as a developer than it does about Ruby.

One just needs to point at Friendster for an example of what happens when your application is too slow at the wrong time. When Friendster started hitting it big, a long time ago, they couldn't deal with the load and they lost a lot of marketshare because of it. On top of it, they undertook a huge effort to rewrite it in something faster, but it was too little too late.

Furthermore, when application availability is crucial to the success of your application, you had better be thinking about performance well before it becomes a problem. Throwing more "metal" at the problem isn't a solution, and you even point it out in your article, "if you can't afford a cluster of Opterons just yet, you're just using some average VPS slice and you're on a tight budget for the first month". Well, if you're on a tight budget how are you going to afford that extra metal to throw at it?

"Good enough" doesn't cut it, and if I'm an investor in your company and the first spike in traffic nearly kills the application and we lose market because of it, well your laziness is going to be the first thing I evaluate.

Note that I'm not promoting any language in response, because it's not really a language issue. Anything you bring to bear on the public, performance should be a primary concern. As a CTO in a company, it's my chief concern, to be honest.

An ounce of prevention ...

I'm a big Rails fan, and have pretty much been using it exclusively lately. However, I've been around the block enough times to know someone trying to cover for a language's weak points when I see it.

I think the honest analysis is: "When considering all the tradeoffs in creating something, the slow speed is not a deal breaker for the kind of app I'm writing. On the plus side, I get something that's very fast to write apps with, a big, helpful, smart community, and the prospect of a faster language in the future".

5 requests/second is "good life average"? While he certainly deserves a credit for trying to shoot conservatively, but such low numbers will only scare more people away.

Our slowest requests (with multiple SQL queries and nontrivial rhtml rendering) get served @25-30req/sec, while "regular", i.e. not heavy requests are served @60-120req/sec and we're certainly not "Rails sharks" having less than a year of real life experience and our server is a $850 Opteron box.

It would be awesome if the hits on your site were spread out completely evenly over the course of a month, yet when is that ever the case. Say you were to get dugg, I have to imagine that at a concurrency rate of only 20 reqs/sec your site would probably go down.

He does have a point. But what still bothers me is that if even a single important part of my app does something computationally expensive (which is typically the case in my apps), I have to interface with C. Writing C code is fine, but the interfacing stuff is no pleasure at all. So I would be glad if Ruby could run, say, 50 times as fast as it does ;-)

well, as long as the choice is between ruby and python I don't really care. Each has its strengths and weaknesses but they are both pleasant language to write things in. Developer time is worth more than CPU time but I think that Python and Ruby would have to be at about the same level in terms of developer productivity (I use both Python and Ruby but I use Python a lot more than Ruby so maybe there is some Ruby magic that I'm not aware of that would make it MUCH more productive).