There was a lot of discussion about the Joel’s post Ruby Performance Revisited. I guess this was just a flamebait, but I’ll bite. Here’s the relevant quote (bold emphasis mine):

Even though our product, FogBugz, seems like something that should be perfect for Ruby on Rails, we have several parts of code where performance is extremely important. In FogBugz 6 there's one place where we need to do literally millions of calculations to display a single chart on a single web page. We have gotten it down to 3 seconds or so in our current development environment with a lot of optimization, but frankly with a duck-typed function call I really don't think we could do it before the web browser gave up and timed out and the sun cooled down a couple of degrees.

So the problem is that there are millions of calculations for a single chart. And Joel’s VBScript based application can handle this in 3 seconds? I don’t think so.

The chance is extremely high that the chart generation is offloaded to a COM component written in C or C++. There’s just no way VBScript could handle this problem any better than Ruby. Ruby can easily call native code too, so why this argument then?

Like I said, I think part of this is deliberate – Joel needs people linking to him (notice the irony; I am aware of that yet I am linking). The second part might be inability to admit that there was an alternative solution to Wasabi (more on this in the next post) and that FogBugz 3/4/5, whichever was the first multi-platform version, could have probably be written in a singe common codebase in PHP/Ruby/Python.

Joel is extremely cool, but this post stinks. Most of the Web applications that do not need to scale “indefinitely” (think Amazon or IMDB) can be equally well written in Ruby, Python, Perl or VBScript/JavaScript. There are other reasons why FogBugz should not have been rewritten in one of these languages, but speed sure isn’t one of them.