Comment by leothekim | Hacker News Reader

Comment by leothekim | Hacker News Reader

Parent Full thread

"I would absolutely love to know what it is about Rails that Twitter found stopped them from working on it together. Please, if you work there, I am dying to know."

I don't work at Twitter, and I'm whitewashing a bit because I'm at work, but the consistent line I've heard from engineers there[1] and from the press[2] is performance. Plus, Scala has shares some linguistic niceties with Ruby that Java doesn't, so it's a little bit more of a natural fit.

From my own experience with Scala, the reason to go in a service-oriented direction is, to say the least, make your compiles go faster over smaller isolated bits of functionality in your app. Scala type safety is awesome. Scala compiles, much less so.

Ruby still runs at Twitter, but my understanding is that the more recent engineers there are afraid to touch what's there for fear of blowing things up.

[1] http://blog.redfin.com/devblog/2010/05/how_and_why_twitter_u...

[2] http://techcrunch.com/2008/05/01/twitter-said-to-be-abandoni...

If I recall, Rails got the bad rap early on because Twitter thought it was the cause. It turned out they were making synchronous calls to a Jabber server, and something in that connection was getting overloaded and causing their apps to hang.

I'm not saying Ruby doesn't have a performance issue over something like a JVM-based language, Go, or Haskell, but the Twitter example works better as an example of the need to debug, benchmark, and test all aspects of your application. Don't just leap to conclusions about problems without information.

> If I recall, Rails got the bad rap early on because Twitter thought it was the cause.

IIRC, it got a bad rap because of one blog post by a Twitter dev that seemed to suggest that Ruby and/or Rails was the cause, which was later followed by a more in depth explanation from Twitter of their reasoning, which didn't place the blame there, but by that time Ruby/Rails haters had permanently latched on to the "Rails was killing Twitter and that had to leave to survive" meme and facts were no longer relevant.

They also had that big huff about ActiveRecord not supporting more than one database system in a replicated environment. Humorously, someone from outside of the organization supplied a patch a few minutes later.

To make matters more complicated, Twitter publicly abandoned Starling, their Ruby-based message queue, for something written in Scala. People took that to mean they abandoned Ruby and Rails completely.

As far as I know they are still using Rails to generate the HTML pages. If not, it is a recent change.

> As far as I know they are still using Rails to generate the HTML pages. If not, it is a recent change.

I think they recently moved that part to the Scala, but it was much later than the other thing.

I don't think they leapt to conclusions. According to [1], they were running into problems with garbage collection issues in long-running Ruby processes. They put a lot of work into doing performance measurement, if Zipkin (https://blog.twitter.com/2012/distributed-systems-tracing-zi...) is any measure.

+1 on this, Recently at my company we encountered performance issues in one of the products, (mongodb, mongoengine ORM, django)...We dove in, isolated separate modules and let them run, figured out some metrics, setup some reporting in AWS and the problem quickly presented itself to us. For the performance we needed, we had to go with a different language (c++) on certain modules. Monitoring like this is something we're going to include from now on, makes the actual debugging and integration testing process much easier.

Let's also remember that this was a while ago. Ruby has picked up some critical performance and GC improvements along the way, including completely replacing the old AST-walking interpreter from 1.8 and before with the bytecode interpreter of 1.9 and newer.

> From my own experience with Scala, the reason to go in a service-oriented direction is, to say the least, make your compiles go faster over smaller isolated bits of functionality in your app.

Compile times are not a reason to move to a service oriented architecture.

I misphrased. It's a side benefit, but a really really welcome one when compiling Scala.

Reply on news.ycombinator.com