This is informally called the Gell-Mann Amnesia effect.
http://harmful.cat-v.org/journalism/gell-mann-amnesia-effect
I don't think it's accurate to say that the news is mostly inaccurate. We just subject material about subject matter we know to a higher threshold of scrutiny than material about subject matter we don't know. We tend to see the inaccuracies as crowding out the accuracies because, thanks to our precise technical knowledge, not getting it exactly right is the same as getting it completely wrong. But to the layman, this is not true. 85% right is not the same as completely wrong and completely useless. 90% right is a good try, not a worthless hack pontificiating about a subject matter he could never possibly in a million years actually understand.
As usual it's all relative. But let's not let our cognitive biases make us too cynical. People generally are trying their best.
Also, I did not mean to say that you should not move to something that inherently runs faster, that would be perverse. However if I have a system written in a language that already works I would probably start by looking at algorithms and architecture before pulling the New Language card.
Once you have a set of interoperating services then re-evaluate which, if any, individual services are my performance bottlenecks that could benefit from the effort of re-implementation in a new language.
The really interesting discussion of course would be one that included engineers from Twitter and their recall about what happened.
I have been in enough design meetings to know that their strategy didn't emerge fully formed from the mouth of one person.
Agreed. But as your article pointed out, Wired apparently didn't want to get into having to do some research. :)
... he said, hoping everyone would accept the statement as fact.
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...