I sympathize with your anger at the Wired article. I too read it and cringed at the misrepresentations. It was either carelessness or a desire to dumb down th

I sympathize with your anger at the Wired article. I too read it and cringed at the misrepresentations. It was either carelessness or a desire to dumb down the subject matter. To my mind, the article is a demonstration of how poorly the media cover just about everything. When you or I read articles about subjects wherein we are not experts, we (or at least I) assume that they are well-researched and accurate. But when we read articles about subjects in which we have expertise, I find I'm routinely dismayed at the inaccuracies. I am no longer surprised by this, but still bothered. It casts a huge cloud of doubt over everything I read in the media. Therefore, I found your rant delightful. Nevertheless, I feel some of your points are subject to debate. You criticize the characterization of JVM as the star of the show affording Twitter and others the ability to scale more easily, considering these efforts were necessarily coupled with a rearchitecture of their entire infrastructure. Of course there is truth in your point, but minimizing the role of the JVM is unfair. The JVM, and especially its higher-performance languages—which include Java, Scala, and Clojure, is a big star in our web application frameworks benchmarks charts [1]. With respect to high scalability opinions vary, but I lean toward the side that believes that while very high scale is ultimately a matter of horizontal addition of servers, a great deal of complexity and pain can be avoided by servers simply being fast at what they do. When platforms perform not merely a few percentage points apart but an order of magnitude (or more!), it's not reasonable—again in my opinion—to ignore raw performance. Simply being faster—massively faster—is like opening a pressure relief valve that gives you a lot of architectural breathing room. Yes, Ruby runs on the JVM, but not all languages on the JVM have proven to reap the benefits. We have not yet observed JRuby demonstrating a compelling superiority to MRI Ruby. Also, as others here have pointed out, many believe that maintaining a large system is aided by a language with type safety. I personally am considerably more productive with a modern statically typed language than any dynamic language. When I make typo-grade errors in dynamic code, and that code makes it to a testing round, or even worse a staging or production environment, I have lost huge amounts of productivity. I end up feeling embarrassed and I long for a static language to prevent this kind of silly failure. Type safety preference isn't a matter that will be settled any time soon or ever, but I believe that at least the general consensus is that for large systems, stricter languages can make maintenance less painful. [1] http://www.techempower.com/benchmarks/#section=data-r6&hw=i7&test=json http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...