Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Twitter is particularly notorious for once being an extremely heavy user of rails, then in ~2010 for abandoning ruby for the JVM and reporting the result was substantially faster.

...this is all ancient history now though. Come on, 2 seconds on google will find all the arguments and counter arguments about this stuff.



Twitter is also particularly notorious for blaming Rails when it is/was blatantly obvious their architecture at the time was a total mess. Including using Rails for stuff that should have been factored out into a separate shared-nothing backend service regardless of the frontend language/framework. They could have rewritten in pretty much anything and made it faster/more reliable.


LinkedIn also had a "Rails->Node" success story where their original architecture used a Rails app as a thick proxy to (apparently relatively slow) backend services. It should be unsurprising that Rails was a bottleneck in that case.

I have yet to read a major "moving on from Ruby" story where it was clear that the use of Ruby and/or Rails was a mistake from the beginning. An architecture that works for 1000 users/day will need to be revised for 100,000 users/day, but that doesn't mean that it would have been a good idea to use the 100k architecture for the 1k product.


Twitter's experience was also on pre-1.9 Ruby, ie. before YARV.

Ruby itself has made major jumps forward in performance since then. Much of Ruby's reputation for slowness was earned on an interpreter that no longer exists. It's still not the fastest dog on the track, but it is a ton better than those earlier days.


I've spent more than 2 seconds on Google for this topic. This StackOverflow post[1] was actually very informative. See the answer by Jörg W Mittag, specifically this quote:

>>In several interviews, the Twitter developers have pointed out that Ruby on Rails was not responsible for their scaling problems. On the contrary, only the maintainability of Ruby made it possible to do such large-scale architectural changes to fix their scaling problems.

Then again, that seems to have been written in 2010. I'm sure things changed since then.

http://stackoverflow.com/questions/3514633/do-ruby-on-rails-...




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: