I like Tony Arcieri, but this is a weak and somewhat unseemly argument, easily knocked down:<p>(1) Most urgently, Alex isn't bashing Ruby. He's at pains to point out that Twitter continues to use and like it. Pointing out the relative strengths of other languages isn't "bashing".<p>(2) The technical problems Alex has with Ruby are bona fide well known problems with Ruby. Put aside the green threads debacle and the MRI VM is still a dealbreaker. I have lots of long-lived EventMachine code, and MRI simply isn't up to the task. Arcieri even stipulates to this in his post.<p>(3) In deriding Kestrel, Arcieri is ignoring several of key facts that Twitter had to face when they built it: first, that they were already down the path of a house-built message queue (they didn't go to Scala to build Starling, which moots his critique of it); second, that apart from Apache, none of the competing projects were mature enough for Twitter to commit to at the moment in time we're bickering about; and third, that his preferred queue (RabbitMQ) would have required them to commit to yet a third exotic platform, Erlang, the Ron Paul of programming environments, and would have won them no more meaningful performance than they got with Scala, but would have robbed them of JVM compatibility.<p>It's the third point that rankles me the most. In a 24 graf jeremiad, we find only 10 grafs in that Arcieri can't make a performance-based critique of anything but a straw man (Starling), and can only do it by himself rejecting Ruby in favor of Erlang. This is the best the Ruby community can do to answer Alex's argument?
<i>As I perhaps somewhat self-aggrandizingly consider myself one of the most knowledgable people regarding I/O in the Ruby world, I decided to peek around the Starling source and see what I discovered. What I found was a half-assed and pathetically underperforming reinvention of EventMachine, an event-based networking framework for Ruby which is the Ruby answer to the Twisted framework from Python.</i><p>The non-evented Starling was multi-threaded and used a thread pool to manage connections. I'm unclear on how that is a 'half-assed implementation of EventMachine' and not simply a multi-threaded network daemon.
Message queues are something the financial industry has been getting right for years (even down to custom hardware-based implementations), so the author brings a good point that it's stupid to reinvent yourself if you don't have an experience.
His analysis of starling reinforces an impression I got of Twitter devs from articles/discussions back when they were having lots of uptime/scaling issues. The impression was they weren't that experienced or all that good.<p>It makes me curious how many early startups aren't composed of rockstar devs. How much (if at all) timing, luck, marketing matter more than dev ability at the beginning.<p>I tending to think it's not nearly as important to have experienced rockstars from day 1. It's not until you get enough success to become famous and start attracting experienced rockstars that it becomes critical to recognize and hire them.