Twitter Should Move Away from Ruby

Oh dear. The chattering classes are at it, talking about how the Twitter folks are dissing Ruby by announcing the replacement of some Ruby code with Scala code.

Please stop.

At the kinds of volumes that Twitter handles (and with what I assume is a somewhat scary growth curve), Twitter needs  to improve concurrency—it needs an environment/language with low memory overhead, incredible performance, and super-efficient threading. I don't know if Scala fits that particular bill, but I know that current Ruby implementations don't. It isn't what Ruby's intended to be. So the move away is just sound thinking. (I suspect it also took some courage.) I applaud Alex and the team for this.

Instead of defending Ruby when it's clearly not an appropriate solution, let's think about things the other way around.

The good folks at Twitter started off with Ruby because they wanted to get something running quickly, and they wanted to experiment. And Ruby gave them that. And, what's more, Ruby saw them through at least two rounds of phenomenal  growth. Could they have done it in another language? Sure. But I suspect Ruby, despite the occasional headache, helped them get where they are now. 

And now they've reached the status of world-wide wunderkind, it's time to move on. 

I for one wish them luck. I look forward to the day when our online store reaches the kind of size where we have to move away from Rails. I'll tweet the fact with a tear in my eye, while my yacht sails me off to the sunset.

Comments

[Giles Bowkett]

Dude, good spirit I guess, but a) you've joined the chattering classes by blogging about it and b) Twitter hasn't moved away from Rails. They've just offlined their message queue to Scala. They still use Rails for tons of crap.

You're not helping bring peace to a troubled discussion, although I'm sure that's your intention and all credit for it. But all you're actually doing is muddying the waters.

If/when Prag Bookshelf ever gets uber-big, you'll still keep Rails code in some places because it won't be worth the bother to change it. Just like Twitter. And you'll still probably get a bunch of people reading deep meaning into that nonevent, just like Twitter.

[Daniel Spiewak]

With the exception of the "low memory part", Scala fits the bill exactly. Which, I assume is why Twitter picked it. As for memory, it's a JVM language with all the advantages and disadvantages thereof. Nobody would claim that the JVM is the *most* memory efficient beast, but it's certainly better than MRI's memory utilization for long-running applications.

The thing that everyone seems to be forgetting (with the merciful exception of people like DHH and PragDave) is that Twitter still does a lot of things with Rails. AFAIK, *all* of the user-facing application is Rails, it's just some of the backend which is (and has been) moving to Scala. Twitter isn't abandoning Ruby *or* Rails. Quite the opposite: Twitter is exploiting the diverse strengths of the many languages which are available to them, including Ruby, Scala, C++, etc. Polyglot programming at its best.

[Yehuda Katz]

> The chattering classes are at it, talking about how the Twitter
> folks are dissing Ruby by announcing the replacement of some
> Ruby code with Scala code.

The twitter folks dissed Ruby by dissing Ruby. Instead of a dispassionate "we needed speed" argument, we got a list of all tropes trotted out against Ruby over the past several years, including a number that are easy to debunk, and completely ignored JRuby in their analysis.

That, not their decision to use Scala when they need super-high-performance, is why people are upset.

[Dave Thomas]

Giles:

I don't think said they've moved away. Instead, I said "announcing the replacement of some Ruby code with Scala code"....

[Tony Arcieri]

I think the negative reaction had less to do with the move from Ruby to Scala itself and more with Twitter's arguments for making the move: they mostly just touted features of the JVM versus MRI (better memory management/garbage collection, works for long-running processes) as Scala is a JVM language. The problem is Ruby is a JVM language too thanks to JRuby, so these arguments don't hold water.

Had they come out and said "We moved to Scala because we need better performance and static typing to manage a larger codebase" and left it at that I don't think you would've seen as much of a reaction.

[nap]

I don't think many of us will disagree that Ruby isn't the right fit for implementing high-speed low-latency message queues. Like you, I'll be excited if the day ever comes when I have to start replacing pieces of my (very quickly implemented!) Ruby queuing services with something else. But the title of this post is more than a bit misleading, which will only stir up more controversy, as Giles correctly points out.

I worry that blog post titles like "Twitter should move away from Ruby" (which will no doubt be trending on hacker news any moment now) give people the impression that Ruby is the programming language equivalent of 'seed funding' -- get in there, do a proof of concept, and if it takes off, reimplement in something else. That's simply not the case. Ruby is a great general purpose language and has some fantastic frameworks for making web development fast and fun. That will continue to be the case, and with more resources being tossed behind it, interpreters will only improve with time. Ruby is good at -- great at -- a lot of things.

It's just not great for writing high speed message queues or finding paths through massive graph traversal problems etc :). It probably never will be good for those sorts of things. Neither will Python. Or Perl. Or PHP. When you get to that stage that we'd all like to get to, selectively replace the pieces that really need the replacing. I know that's what you're saying, too. Just change the post title please :).

[David Vydra]

Giles,

Why do you think its a good idea to keep Ruby if Twitter has, say, 1M concurrent users on their Web UI? Its wasted energy! At that scale it makes sense to use the JVM.

my $0.02
David

[hans]

i seriously don't get the popularity of twitter... and no layman i know knows of it either... where is this popularity coming from?

[kevin]

Scala is a semi-dynamic / functional language that runs on the JVM. Ruby is a fully dynamic language that runs on the JVM. *Both use JVM threads for threading and concurrency.* Using the JVM to gain concurrent threading performance is wise, tossing out decent Ruby code that could use the JVM to achieve those gains in favor of a different language that also runs on the same JVM is insane*.

I used to defend Ruby scale by using Twitter as an example. From now on I will use Twitter as an example of poor technical choices and shortsightedness every time they have a service outage.

I'm still very interested in Scala for Erlang-style concurrency *code style*, but I know it's just Java underneath, just like JRuby.

* Insanity - doing the same thing over and over but expecting different results.

[DanF]

I hadn't even heard about this till seeing Dave's post here. I think it's a good one though, that's why they are called "pragmatic programmers", not Ruby Fanboys.

Good call Dave :)

-Dan

[Peter Cooper]

FWIW, I agree with you all the way, Dave, which is why I haven't bothered to editorialize on what, to me, seems like a non story. Good summary for your part though.

[Sebastian]

I think you've hit some very good points. In a sense, I think your title is right on. If the folks at Twitter don't think Ruby is the right solution for some of the issues they're having, they should use something else.

And even in the "Twitter on Scala" article, the guys *do* say they like Ruby and Rails for a lot of things.

I keep thinking of Kent Beck's "Ease at Work" talk all through this debacle. Why can't we be civil and reasoned "geek to geek" about this stuff?

There was a time when Ruby did not exist. People were passionate about something else at that time. Sometime in the future, another platform will introduce revolutionary concepts. And flame wars will occur over that.

while true { Wheel.keep_spinning }

Anywho, just my two cents. :)

[Sam]

I wholeheartedly agree with Tony and Kevin. Jruby and even IronRuby (burn the witch!) are superior replacements for MRI. Just by virtue of being on the JVM the twitter guys would have gained access to a world of tuning instrumentation.

It is a real shame that Twitter seems to have become the posterboy for RoR development: they seem to have made poor design choices and continue to seem to do so. Whats the adage? "A rewrite is not the answer?"

I wish the guys at Yellow Pages, Rails novices themselves when they began the project IIRC, would evangelize more on a technical level. Then again perhaps it's better business to just get on with generating revenue quietly and effectively than to get involved with the saga of a startup that continually looses its way. Chattering class indeed.

[Dr Phallus]

stop being sensible need more rage.

[Markus Hergenröther]

Nicely expressed Dave.

I fear however that people who dislike ruby (for whatever petty reason they may have) try to depict it as if ruby is a bad language because IT IS SLOW. (The slowness factor has always been brought up before concurrency or scaling issue by the way.)

More importantly I suspect - or expect? - that some vocal Python users will try to jump on that bandwagon claiming that this won't happen with python because python is super fast. (I dont expect perl people to say that because they seem to be dying rapidly anyway.)

[James Bennett]

Hmm... Devil's advocate time.

If there were an RDBMS implemented in pure Ruby, and Twitter had announced they were switching from that to (MySQL or Postgres or some other database solution implemented in C), would it be a story? Or would people say, "well, the DB's usually a bottleneck, might as well use the fastest, most performance-tuned thing you can get"?

Obviously I don't know much about Twitter's internals, but I'd wager that message queues, for them, can be just as much of a bottleneck as the database is in most web apps (perhaps even more so). It makes sense that squeezing out the performance they need will require more than just the stock C implementation of Ruby.

And, frankly, I don't think we're at the point yet where dynamic languages on the JVM are going to get the kind of performance you need in that type of bottleneck situation. So JRuby probably isn't an option, same as Jython wouldn't be if Twitter were written mainly in Python (ditto IronRuby and IronPython if they went the CLR route).

This comes down to a simple issue: while the JVM already has to handle a fair bit of dynamic support simply because of the way Java works, everything I know about it indicates that it still does its best optimization work (by quite a large margin) when it has reasonably complete type information to use as a basis for its heuristics, and no dynamic-language-on-the-JVM implementation currently can do that. Scala, on the other hand, can do that and even though it's laden down with huge amounts of syntax it's still leaps and bounds nicer to work with than Java.

If anything, I'm surprised that they went with anything other than C here; the JVM's good and getting better, and is best with long-running applications (to the point where it can start to catch C for performance, given the right code and the right tuning), but hand-tuned, low-level C is still the standby for bottleneck components (which is, returning to my original analogy, why we still use databases written in C). I'll be interested to see if they can get Scala to give them the performance they need, or if they'll end up having to ditch that too in the future.

[James Cunningham]

@Kevin:

"Ruby code that could use the JVM to achieve those gains in favor of a different language that also runs on the same JVM is insane*."

Except that, when the Twitter folks made the decision to go with Scala, JRuby wasn't even as fast as MRI; it's *still* not as fast as YARV. Additionally, given that they used C extensions which hadn't been ported to JRuby, they would have had to do major rewrites anyway. And even if we pretend that JRuby-of-today had existed a year ago, Scala would still outperform JRuby in a pretty major way.

It wouldn't have made sense to go with JRuby. I find this ongoing discussion baffling.

[Dave (not prag)]

I agree that Twitters handling of the publicity around has been pretty terrible, though the reporting/chattering has been pretty bad too.

The real story is far more interesting than the, basically fake, controversy. Apparently they evaluated a bunch of message queue implementations, in languages as 'cool' as erlang, and found them wanting for their, very unique, needs.

They went with Scala because an employee had already ported their home-grown system to that language on his own time and when tested against the other 3rd party products they found it fitted them best, at least partly because it was ported from a homegrown system by an insider.

So they didn't "choose Scala over Ruby", they'd already moved the bottleneck of their homegrown Ruby system into C (a standard Ruby thing to do), then they went looking for a 3rd party stack, just like you'd pick a database or webserver. So Ruby was basically out the picture whatever happened, and as Dave says, that's a no-brainer.

They then didn't "choose Scala", they chose an implementation that fitted their situation best and it happened to be in Scala. It could just as easily have been in Erlang or whatever.

The final irony: the core of the "Scala" system is an Apache product (Mina) written in plain old Java (aka 21st century COBOL), very analogous to the Ruby/C things that people seem very comfortable with.

[Smokey]

As pointed out Jruby may not have been a realistic option when Twitter decided to move to Scala. And Jruby today might still be still be too slow for their crazy throughput requirements.

Having said that, I do think JRuby deserves more consideration than it is often given. It is a first class JVM language. It's approach YARV speeds, but more importantly it supports threading (without the global interpreter) lock. And when things are still to slow you can always dive down to Java -- or Scala!

[Pau Garcia i Quiles]

They should move to Wt ( http://webtoolkit.eu ). It's C++, provides very nice ready-made widgets and it scales like hell. You can deploy it using its own embedded HTTP(S) webserver or as a FastCGI module with Apache, IIS, etc.

[Jeff Judge]

I think this is a totally fair post - Ruby isn't an optimal language for messaging. That's not at all taking anything away from Ruby/Rails - it's a great framework.

Speaking from personal experience...for our TextMe app, we started out using AP4R w/reliable messaging and we'd run into memory and db connection issues under load. We swapped that a few months back in favor of RabbitMQ (Erlang) and it's been great so far. Given that Ericsson designed Erlang, and RabbitMQ was written on top of a telecom platform, we figured it was a good fit for our needs. We're processing >5m SMS messages/month, distributed across 4 machines with plenty of room for growth. I imagine Twitter is processing a massive amount of messages every day, thus moving to a language like Scala (or C++ or Erlang) makes a lot of sense.

[Smokey]

Twitter moving to scala for its backend stuff makes perfect sense. Some of the things Alex said in his post didn't make sense however. I didn't understand the bit about 'creating your own type system'. His example was a client needing to know, for example, if something was a User object or something else. Why would a client need to switch on the type in any language? That'd be ugly in scala too. Polymorphism anyone? That did sound odd.

[Christoph]

If they think they have to move to ASSEMBLER, so what. Have fun.
Ruby still rocks.

Cheers,

Chris

[gems]

I would like the move away from ruby. they have been just hurting the community

[gems]

anyway, I think scala or erlang + ruby(optional) for backend is perfectly OK.