Lots of people are invested in the "Ruby is slow (but I don't care)" meme. Benchmarks establish that Ruby is just about the slowest serious language out there. Enthusiasts counter that Ruby is fast enough for most tasks, that programmer productivity is more important than processor productivity, and that there is nothing intrinsically slow about Ruby -- faster implementations are on the way.

Both perspectives are valid, but Avi Bryant makes an excellent point that has been mostly overlooked: Ruby's internal optimizations have made the language more difficult to understand and implement. But wait, you say. "Ruby optimizations? I thought the language was slow." Exactly. And because it is slow, much more of the core is written in C. This implementation choice leads to some unintuitive behaviors, although (as Avi's example demonstrates) you will not encounter problems unless you are doing very odd things. The more important effect is on language implementers. Avi argues that the JRuby team has to work much harder because the core is too large. The core is too large because of an optimization that was probably necessary at the time, but will seem premature in hindsight five years from now.

Except that the problem will be gone in five years. We can fix this one.