Twitter jilts Ruby for Scala

http://www.theregister.co.uk/2009/04/01/twitter_on_scala/

by astrec • 17 years ago

85 78 17 years ago

theregister.co.uk

petercooper• 17 years ago

And in case you're wondering.. no, this isn't an April Fools joke.

tptacek6• 17 years ago

In this case, it'd've been a joke cued up several months ago, when this story first broke.

nessence• 17 years ago

"And he's pitching his new Scala book. And his new Scala book is published by O'Reilly. And O'Reilly runs the Web 2.0 Expo. ®"

Timing is priceless.

sachinag• 17 years ago

So what? He likes Scala. Likes it enough to write a book in his spare time, of which he has precious little since he's, oh yeah, a full-time developer at one of the biggest, fastest growing sites on the face of God's green earth.

So it's a (mild) conflict-of-interest (really, it's just a promotional opportunity). Doesn't make the arguments any less valid or his book any less worth picking up. Nice thing about code is that it's like science - every claim can be tested ad infinitum.

Semiapies3• 17 years ago

And if the Scala reworking goes poorly, he presumably suffers, too.

One idle thought: It'd be hard to eliminate the factor that they might be a better Scala dev team than a Ruby dev team. That's still, of course, a perfectly good reason to go to Scala.

jseifer• 17 years ago

"Investors now want to know that you're not going to be paying tons and tons of money for servers because you decided to build in a stack that isn't as efficient as possible," he said.

I've never used Scala and I'm a Ruby dev but I'm still not sure I totally agree with that. Scala is probably great and very efficient but you probably don't need to be thinking at Twitter's level out of the gate.

tptacek6• 17 years ago

It's also the case that headcount is far more expensive than servers.

rcoder5• 17 years ago

A really talented sysadmin with good tools may be able to manage 100 servers; a great developer can optimize your algorithms to get an order-of-magnitude reduction in the number of servers you need.

Eventually, more servers == more headcount.

Tichy• 17 years ago

Still, I worry that despite Ruby's niceness, a lot of time is spent developing around it's issues. Whenever I read about deploying Ruby, it just sounds scary. Memory munching Mongrels that have to be restarted on a regular basis? It sounds like a science in itself, whereas tomcat just runs and runs and runs. Less headaches == less headcount.

erlanger3• 17 years ago

I think that users care about speed as much as anything, and being fast cheaply is a competitive advantage.

charlesju3• 17 years ago

Having 2 RoR products in the time it takes you to build 1 Scala product is the true competitive advantage.

patio11• 17 years ago

Some of us have business models which do not require traffic the size of nation states and, accordingly, aren't exactly that intensive on the computational resources.

My side business runs off of a $20 a month VPS. My day job routinely charges millions for software that runs on one to three commodity boxes.

You'll forgive me if I don't consider "Has difficulty running Twitter" to be a knock against a language. I don't, after all, have to run Twitter.

zmimon• 17 years ago

The very title of this article shows the religious nature of much of the hype around dynamic languages. Why is using the right tool for the job "jilting" another language which was never designed or meant to be suitable for the same job?

I am curious though whether they tried running their Ruby code using JRuby ... if the bottlenecks were (as stated in the article) in the ruby VM they might have got the same result just by switching VMs (pure speculation).

And ...

> "The biggest selling point for certain organizations is that Scala is 100 per cent compatible with your existing JVM code.

No, it's not. There are problems with quite important features like annotations etc. which are now very important in the java EE space but Scala cannot do them. This was one reason I've used Groovy so far in a lot of situations.

Having said that - I'm seriously looking at Scala because groovy has plenty of faults: the complete lack of any static type checking at compile time and very poor IDE support and error reporting all weigh down on the productivity benefits to the point where it's sometimes a net negative. Scala could end up being the best of all worlds.

michaelneale2• 17 years ago

>Why is using the right tool for the job "jilting" another language which was never designed or meant to be suitable for the same job?

That would be a question for the journalist who made it up ;) I am sure the answer was "cause it sounded cool !".

jhancock• 17 years ago

that's pretty much how "the Reg" operates.

Without regard to the tone of the article though, Scala and Lift are worth spending some time with.

Lift still has a ways to go in terms of providing a turnkey stack in the same vein as a Rails or Merb stack. If you thought putting together a Ruby dev environment had a lot of pieces, get ready for Lift...not so much Lift's fault as its the nature of the heavyweight JVM toolset world.

beza1e1• 17 years ago

What doesn't work with annotations in Scala? The documentation looks like Scala supports them. http://www.scala-lang.org/node/106

jorgeortiz85• 17 years ago

Scala doesn't support nested annotations. That will most likely change with 2.8.0 when Scala gets optional and default arguments (nested annotations being a convenient side-effect).

That said, most real-world uses of nested annotations in Java can also be configured with XML (I know, yuck). Or you can always write a wrapper interface in Java and use that from Scala, since Scala supports mixed compilation projects. Needing nested annotations in Scala won't be a show-stopper, just inconvenient.

awt• 17 years ago

it seems that the article ignores the trade off in cost between efficient code and development time.

jimbokun• 17 years ago

Scala tries to be pretty good at both. Java like speeds, with type-inferencing, first class functions, and a more flexible syntax to improve programming productivity.

ewjordan3• 17 years ago

Maybe the article ignores that trade off, but Twitter is not really a "startup" anymore, so they are correctly leaving the startup mindset behind and beginning to analyze where they are wasting resources and what they can do about it.

If the expected total cost of rewriting and maintaining the codebase (over and above the cost of maintaining the current code, of course) to get an N% efficiency increase is less than the amount you will save on hardware, then it's worthwhile to do.

For a relatively simple application, which Twitter is, I'm unsurprised that a re-write/port is a fairly low cost ordeal, and might provide enough savings over time to be worthwhile.

I also take issue with the implicit claim that RoR is automatically more productive than Scala + Lift - Lift might be a little younger than Rails, true, but it's still a pretty solid piece of work, especially if you don't have to beat against the edges too much. And if you put some experienced Scala people up against similarly skilled Ruby folk in a "code race," I'd expect it to be a pretty fair match. This is not Java we're talking about, Scala can be extremely powerful in the hands of someone that knows what they're doing, and I imagine the Twitter guys have enough of those people that they'll do just fine.

alecco5• 17 years ago

Unfounded claims, no research, nothing. After years of suffering websites running on JVM web stacks, I am very sceptic of this Scala for the web rant. Plus he extrapolates Ruby to Python and PHP just because. The JVMs (there are several) mostly trade-off memory for speed. Go check the Language Shootout page. It doesn't scale in my book.

So unless Scala has some secret ingredient to use the JVM more efficiently, this looks to me as yet another fanboy rant.

rcoder5• 17 years ago

First of all, I don't think it's fair to accuse the Twitter dev team of working without real experience and numbers to back up their decisions. They have a huge volume of data being generated by their service, and have weathered the whole "Rails doesn't scale" flame-fest with relative grace and good humor. IMHO, that entitles them to talk fairly freely about the relative scalability of different languages and frameworks.

Secondly, any "ranting" you hear in this article is the product of El Reg, not Alex. He mostly offered a calm, positive presentation about the improved speed (with relatively little, if any, tradeoff in developer productivity) that came from using Scala instead of Ruby for critical infrastructure services.

Regardless, most Java web applications' performance issues stem from framework-itis, not from the underlying runtime. By itself, Tomcat (or another modern Java servlet container) is capable of some pretty impressive throughput -- perhaps not on par with a lean, pure C server like nginx, but not nearly as limited in functionality and extensibility, either.

No matter what you think about Java the language, you at least have to admit that HotSpot blows MRI, YARV, the Python VM, and Parrot out of the water when it comes to raw performance on low-level code. That doesn't save you from bad implementation ideas, but it does at least give you the possibility of getting fast, efficient code, if you have a decent compiler and work fairly close to the metal.

Using Scala is one way to produce that sort of low-level implementation code without wanting to gouge your eyes out (which is how most Java source tends to make me feel, anyway).

alecco5• 17 years ago

No, the JVMs use memory like crazy themselves, it's not just the frameworks. As I said, check out the Language Shootout. Java, in almost every test, is several times bigger than most other languages.

The rest of your comment, you change what I said so it's not worth addressing.

axod• 17 years ago

Java scales just fine thanks. FWIW, Mibbit handles a good number more messages per day that twitter. On a single VPS with 1.4GB ram, running Java.

alecco5• 17 years ago

  > Java scales just fine thanks. FWIW, Mibbit handles a good number more messages
  > per day that twitter. On a single VPS with 1.4GB ram, running Java.

I wasn't talking about that. Message passing is trivial and scale on any language, or at least it should be. Well, unless you do Java and XML. That doesn't scale, from experience. Unless something changed in the last couple of years I'm not aware of. (Just taking your red herring further, to show it doesn't make sense and it has nothing to do with what I said.)

Third time lucky, I hope. My point is I seriously doubt Scala is much better at scaling than Ruby, Python, or PHP. And the author seems to have based his opinion on his experience refactoring Twitter components previously coded in Ruby in Scala. Caveat emptor, I wasn't at the conference and this rant is second hand via a questionable source, The Register.

ewjordan3• 17 years ago

Careful here: are you _really_ suggesting that Twitter would do a full rewrite without making sure that it would increase throughput first?

I don't get the sense that they are that inexperienced. If they think a switch to Scala will handle more volume, I'd be really shocked if they didn't have some solid evidence to back that up.

alecco5• 17 years ago

  > Careful here: are you _really_ suggesting that Twitter would do a full rewrite
  > without making sure that it would increase throughput first?

No. I say this Scala vs. Ruby/Python/PHP rant sounds farfetched and unfounded.

oomkiller• 17 years ago

I think anyone who has any depth of experience with Ruby can attest to the flaws it has data-intensive tasks. Thats why many of us just drop down into another language when we need to get something done efficiently. Ruby's clarity and conciseness make a lot of sense when writing views, controllers, and models, but don't have the same effectiveness in a background process that needs to be written and forgotten about.

Unless there are some major changes in Ruby (MORE than 1.9), I believe that it will be relegated to simple web applications, and never really be good at processing tons of data.

And honestly, isn't Ruby really just about prototyping? I admit, its great for startups who have nil for cash that need to get something written QUICK (to get money from investors), but once you cross that threshold, why not write it over with a language designed for efficiency?

ashot• 17 years ago

I'm not a ruby dev, but could you be more specific? Assuming you are refering to syntax, not speed: how is it good for prototyping but not "data-intensive tasks"

fizx2• 17 years ago

One example: Ruby has slow IO and text-processing capabilities. I sometimes write pipeline tasks in Ruby or Perl. i.e. while line = STDIN.gets; puts transform(line); end. Typical disk bandwidth is 2MB/s in Ruby, and 25-120MB/s in Perl, Java, Awk, or C.

Beyond that, a lot of the metaprogramming features that make Ruby cool are also expensive when done repetitively.

Also, Ruby's threads REALLY suck. And it has impossible to track down memory leaks in the interpreter. Ask mojombo about fun with those.

emmett• 17 years ago

All of the Ruby runtimes are unreliable (buggy) and very slow. Ruby syntax is perfectly good for "data-intensive tasks", but the current runtimes are not.

swombat• 17 years ago

Data-intensive tasks that you do every day, or every hour, or every minute, require efficient execution above all else.

Prototyping tasks require efficient programing (as in, the act of putting the program together) above all else.

Ruby excels at the latter, but not (yet) at the former.

wheels• 17 years ago

This really hit home for us when we started messing with TweetRex. It was my first project in Ruby and things seemed to go well -- the language has nice syntax, good selection of libraries, the prototype was done fairly quickly...

...and then I had to rewrite 80% of it in C++ because of the horrible threading, slow string manipulation and high memory usage.

It was still an interesting experiment, and I intend to continue to use Ruby for stuff where performance doesn't really matter, but I was surprised to learn so vividly that the Ruby bashing that I'd assumed was oversold was in fact pretty much spot on.

c00p3r• 17 years ago

That is so funny to choice JVM-based stuff is case when you need an accept/select/read/write hardcore (message passing) along with queue processing. Of course, you can do networking from JVM, and it works well in clean cisco-branded qos-enabled networks. =)

If one had had an experience of using java-based network tools over cellular or wireless networks, one knows.

At the same time, Erlang is around for a decade.

intranation• 17 years ago

This quote:

"The trouble, he insisted, is that the so-called Web 2.0 languages aren't always as efficient as they need to be, especially in an economic environment threatening to bring Web 2.0 to its knees."

Is particularly dire. Sure, so if we all switch to C or machine code we'll be able to skip through the recession, right? Seriously, less drama and more reporting please.

jpcx01• 17 years ago

Seems like a perfectly reasonable approach. They still are going to continue using Ruby on the front end of the site. It's just the backend message queuing, and data operational stuff that they're moving to Scala.

I probably would have just used JRuby for this stuff, but Scala seems fine to me. And if it works for them, thats great. But I hardly see this a "jilt" against Ruby.

dkarl3• 17 years ago

JRuby is what, a few times faster than Ruby 1.8.x? In a situation where Ruby was too slow, even after optimization by experienced Ruby coders, I don't see how switching to JRuby would have helped. Is there a crucial performance difference (threading maybe, or libraries) that would have made JRuby scale better than Ruby in this case?

jpedrosa3• 17 years ago

I use JRuby to run a web application that I first coded in Ruby and it works pretty well even though it reserves and consumes more memory. Having a dedicated server for JRuby applications instead of running such applications on your own desktop alongside other applications slightly helps with the feeling of speed of the JRuby application, as it does not compete for CPU time with the other desktop applications you have like the browser, when you can feel that JRuby requires more work than Ruby for doing similar workloads. :-)

I know that the pros of JRuby for running Ruby applications mean things like being able to run multiple instances of Ruby from the same process, being able to run JRuby applications in a standard Java web-server be it as Servlet or a more high-level installation, and so on.

Also, Java has had a lot experience in running server applications so Java does help with maximizing the use of the resources available, be it 100% of CPU time, gigs of memory, multiple CPUs, and so on. Java has those famous garbage collectors and HotSpot technologies. JRuby can enjoy all of that so it does improve things over pure Ruby. Let's say, Java doesn't break a sweat under heavy load, or at least it shouldn't. Whereas with pure Ruby all bets are off.

donal2• 17 years ago

Sheesh, from the comments you'd think The Register is known for level-headed journalism.

It is a snarky, piss-taking, grease-trap that mixes news with commentary with little to no discretion or fear of violating "journalistic integrity." Once you understand that, it becomes a great source of news and entertainment.

jrockway3• 17 years ago

Once you understand that, it becomes a great source of news and entertainment.

Or rather, a great site to ignore.

nir• 17 years ago

Carpenter jilts saw for hammer

[EDIT: dear downmodders, the intention here is that languages are tools, and you pick the one which fits your current needs best. What's good for Twitter isn't necessarily best for another app, and Scala <=> Ruby is meaningless]

alecco5• 17 years ago

HN is getting lamer than ever with this downmodding of anybody who doesn't conform. It would be interesting to know the overlap of opinion-based down-modders and Reddit/Digg bashers.

jpedrosa3• 17 years ago

Seeing the April 1st date of the article it was just a little bit harder to believe they would write it like that. As folks have taken it seriously...

The Ruby community was formed without being forced into it necessarily. Academics did not force people into Ruby. Businesses did not force people into Ruby. Even Ruby on Rails was created because DHH was not forced to use PHP and instead tried to make things work in this new called Ruby.

Scala has its followers but Academics push it and business types can push it as well even though many business types still prefer Java and C#. Also, Scala is being primarily used for server-side stuff which is a very crowded market already and many developers are just a little bit too tired of having to interface with complex server-side stuff while trying to innovate on the client-side.

Thing is, as a guy who really digs Ruby, Scala does not worry me one bit. I could always try and use a hyper-advanced Scala implementation or application in the future given I can make choices at one point and then have to revisit said choices in the future given the changes brought by new developments.

Let me tell you a little story. When C# was being first introduced in its very early versions, I was very much playing Ultima Online on pirate servers. A new pirate server was being coded in C# and it was becoming rather popular quite fast and the single developer (or was it?) was having quite a lot of fun with it. Nobody told him to use C# for that kind of thing I am sure, it was just him putting his passion forward with the means he had at the time. C# has grown since then, and many pros and hobbyists use it to create all kinds of little programs on Windows.

Scala? Scala has an uphill battle, and many other languages have had their own uphill battles throughout the years. It's tough.

jrockway3• 17 years ago

Uh, who cares?

Some day you will realize that programming languages are tools for getting work done, not religions.

Semiapies3• 17 years ago

Following Twitter's issue blog, most of their problems appear database-related. I wonder whether a shift to Scala would have any real effect.

cosmo73• 17 years ago

Threading.

Semiapies3• 17 years ago

Hmm, I could see that. I just wonder how many of their problems actually come down to thread issues.

May just have to wait and see whether their new "beautiful code" does any better. :)

cosmo73• 17 years ago

Although the Reg sensationalizes the story, it's interesting to see how Ruby is in limbo. How much damage has been done to Merb by the 1.8 to 1.9 fiasco?

jpedrosa3• 17 years ago

I agree that the Ruby 1.8 to 1.9 transition has caused headaches. But the 1.9 version does have some interesting features that have been long being cooked to get to this point, and perhaps more interesting is that the 1.9 version has motivated even more developments in Ruby-land as found in MacRuby that uses the 1.9 version or in yarv2llvm that recompiles the bytecode to llvm or something.

Let's say that many folks might have had higher expectations that have been hard to meet given the reality of it all.

The Merb guys helped with further explorations themselves which probably helped with making Rails advance more decisively, given the promissed "merging" of the Merb ideals with Rails.

Also, with things like Passenger, the deployment of Ruby met an all-time high in features.

dpnewman• 17 years ago

I think it's important to remember that Twitter had this problem because they were ULTRA successful to the degree of being a household name, a new cultural lingo, a game changing tech of enormous value, etc.

Yes, different languages and techs for different advantages and purposes.

"Just" developing a web app with models and views and controllers is enough to create the user experience smash hits are made off. Scaling issues are big, but certainly fall in the class of problems we want to have at some point.

antirez2• 17 years ago

> Scaling issues are big, but certainly fall in the class of problems we want to have at some point.

Well actually with a big of good design from start you may avoid this problem from the start with little efforts. You'll have to scale anyway but it will be a matter of buying more hardware and not redesigning the system.

antirez2• 17 years ago

I don't understand a lot this approach. Basically the front-end is almost always not the problem, but the Db / backend is. And this should be written in C probably. If you write a queue system in Ruby and it's slow where is the news?

The article title is misleading since Ruby continues to be used for its core business that is the front end.

Twitter jilts Ruby for Scala

Related Stories