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 performan

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 ...