Hacker News Reader

Comment by pico303 | Hacker News Reader

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.

View on HN

> 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.

Reply on news.ycombinator.com