Over the last couple of days there has been a running debate concerning the scalability of Ruby. In his post on the Language Wars, Joel Spolsky argued that Ruby on Rails was not yet a safe bet when building large scale web applications. Joel's primary argument was that there is not a lot of real world experience available to know how well Ruby will scale or how easy it will be to overcome other technical obstacles that occur on most projects.
For some reason this has sparked a bit of backlash. Joel revisited this topic a few days later and said:
I understand the philosophy that developer cycles are more important than cpu cycles, but frankly that's just a bumper-sticker slogan and not fair to the people who are complaining about performance.
This did not sit well with Jeff Atwood who believes that Joel may have jumped the shark, or Phil Haack who thinks Joel may be reaching and believes that Ruby on Rails can use the same performance optimization techniques employed by other languages (including Wasabi, which is the DSL used for writing FogBugz).
Both of these posts miss the original point that Joel was trying to make: Ruby is still not a mature language, and Ruby on Rails is even less mature. There is no evidence yet that Ruby or Ruby on Rails applications will scale to the level typically required for many large scale web applications. There are well documented performance issues, that Joel rightly points out.
Phil believes that developer productivity is an important consideration when building an application and that early in product development, this productivity should trump raw language performance. I reject this view when you are talking about using an immature language.
Developer productivity is not just a matter of how many lines of code it takes to write an application. It is also measured by the tools available to help develop and maintain the code. Can I easily refactor my code? Are common design patterns well documented for the language? Are common anti-patterns documented? Are solutions to common technical problems readily available and functional in the chosen language? What kind of debugging tools are available?
When a developer is forced to use immature tools, a greatly reduced body of knowledge about how to solve common problems using a given language and must also accept a large performance penalty, then I would argue that this is probably not a language that should be near the top of the list when choosing a language for your next large scale application.
Jeff throws up a strawman argument that because Joel uses Wasabi for developing Fogbugz, then his arguments against Ruby are without merit. This is a totally fallacious argument. Joel chose to develop a Domain Specific Language to meet his needs when developing Fogbugz. His company knows the complete set of requirements for both the language and the target application. As application requirements evolve, Joel is free to evolve his DSL to solve those problems in a very efficient manner. Since Wasabi is written in C#, evolving the DSL is not a herculean task. The tools for maintaining Wasabi are mature and the body of knowledge is quite large. His DSL is nothing more than a very intelligent code generator. This however is completely different from the original argument against using Ruby on Rails for a generic large scale web development, where the success of your company may be on the line. If you run into a roadblock in Ruby or Ruby on Rails, there is no guarantee of a cheap or easy fix. In fact, because of the immaturity of the platform, there is a much greater risk that you will run into a roadblock. And there is a good chance that you may well be the first person to document this technical hurdle. At this point, developer productivity drops to zero.
As we have found with DotNetNuke: identifying and resolving performance problems are hard enough when you have mature tools available for troubleshooting, and when you have lots of developer knowledge available to aid in solving tough technical problems. To choose a language where you are almost guaranteed to have more technical challenges, while also having a smaller developer base, and immature tools does not seem to me to be a good bet. Choosing Ruby on Rails for your web project necessarily carries a much larger risk than using one of the proven stacks.