Twitter developer hints it may not be hot on Ruby on Rails after all

Can the recent plague of technical problems affecting text communications service Twitter be blamed on the language on which its platform was designed? Earlier, the company said no...but some within the company are hinting otherwise.

Two weeks ago, following the rapid spread of rumors that the Twitter service -- recently besieged with technical troubles -- may be abandoning the Ruby on Rails development platform in building a replacement platform for itself, the company's co-founder Biz Stone flat out refuted those rumors in a comment to BetaNews.

But that didn't stop Twitter's loyal followers from wondering whether some kind of "slow exodus" was in the works, a gradual weaning of Twitter from the rapid development platform, which enables database-driven Web applications based on the dynamic language Ruby. Recently, some of those followers posed their questions directly to Twitter's development team; and in a blog post featuring members' questions yesterday, one of its software engineers responded to two of them.

The answer he gave suggests that Stone's pledge not to abandon Ruby on Rails, while indicative of his company's policy, may not be all that heartfelt.

"We've got a ton of code in Ruby, and we'll continue to develop in Ruby with Rails for our front-end work for some time," began the response from Twitter's Alex Payne. "There's plenty to do in our system that Ruby is a great fit for, and other places where different languages and technologies are a better fit. Our key problems have been primarily architectural and growing our infrastructure to keep up with our growth. Working in Ruby has been, in our experience, a trade-off between developer speed/productivity and [virtual machine] speed/instrumentation/visibility."

Last week, Payne attempted to explain some of the technical issues Twitter has been having as an evolutionary problem. The platform it chose to build itself upon, he said, was originally based on a content management system. Developers apparently thought they could adapt that CMS to suit their needs over time. But as it turned out, Twitter actually required more of a communications infrastructure than one suited for CMS.

As Payne wrote last week, "Over the last year and a half we've tried to make our system behave like a messaging system as much as possible, but that's introduced a great deal of complexity and unpredictability. When we're in crisis mode, adding more instrumentation to help us navigate the web of interdependencies in our current architecture is often our primary recourse. This is, clearly, not optimal."

A great many of those interdependencies are generated by virtual machine architecture -- and in this case, we're referring not to the kind of virtual machines that a server farm would use to provision new servers dynamically in case of traffic overflow, but instead the kind most often associated with managed languages like Java, Python, and Ruby. With the scale of the Twitter network growing exponentially, the question many developers have, including those who use and love Ruby, is whether there's a maximum limit to the effectiveness of managed code in managing a global communications complex.

In a blog post earlier this month, independent Web developer Ryan Twomey speculated that Twitter's cause may not be with Ruby's or RoR's evolution at all, but rather Twitter's -- as a business.

"The main problem it's [Twitter] got is that it's [RoR] the new kid on the block, and all those scaling experts Twitter's been hiring have experience in things other than RoR," Twomey wrote. "Their natural tendency is to favor something they know works. But...they can choose whatever language they want, because ultimately, they're solving the wrong problem. My issue is that I don't buy that RoR is the actual problem here. A business, like Twitter's, that is so dependent on database access is going to have issues with their databases way before anything else. After all, what is Twitter other than a front end to a database with millions of 140-character rows?"

One of the new features RoR engineers look forward to testing is new language tools, similar to "pragmas" in low-level object-oriented languages, that enable programs to declare dependencies to their own add-ons, or what Ruby calls "gems." This way, a Ruby-based program can manage its own dependencies and establish its own working environment, rather than rely on the installer program to perform that task for its benefit.

Just as exciting for many developers is the news just this morning that Microsoft's IronRuby, which is RubyCLR creator John Lam's implementation of his language for the .NET platform, and released to the open source community last year, has been modified to run RoR unmodified.

In his announcement on the IronRuby blog this morning, Lam wrote, "This is an important milestone for IronRuby; it's our 'ticket to entry' to the world of alternative Ruby implementations." A public demonstration of "IronRuby-on-Rails" could come before the RailsConf conference closes tomorrow.

But will all this development in the Ruby world end up leaving perhaps its most critical customer behind? BetaNews has an inquiry filed with Twitter's Biz Stone (using old-fashioned e-mail), and his response may be forthcoming.