Hacker News new | ask | show | jobs
by SwSwinger 981 days ago
Twitter also had to move away from Ruby into a service-oriented architecture back in the late 00s. It's not a very scalable language, even when you hire people who work on the compiler.
4 comments
chris12321 981 days ago
DDH made a funny comment about this in his keynote for the Rails World conference that just happened:

"Twitter moved off rails and I was always really curious about that story. Here's a testimony from someone who actually worked at Twitter when they moved off. Yeah they moved off because they had a badly designed Rails app, that happens. Okay and then they moved into what they thought was better a constellation of java microservices and then nothing fucking happened for 10 years. They poured concrete over the application and hired thousands of people to make no progress at all."

You can watch the whole talk here, the quote starts around the 15 min mark:

https://www.youtube.com/watch?v=iqXjGiQ_D-A

link
busterarm 981 days ago
Twitter had to move away from Rails because their high-volume read/write pattern of unrelated data doesn't scale on rdbms and that made ActiveRecord a poor fit for tweets.

They famously and stupidly blamed Ruby and everyone ate their blogpost up because this industry is full of cargo cult behavior patterns. Everyone acts like lemmings and just assumes BigCo knows better than they do.

link
vladgur 981 days ago
It seems that the Ruby on Rails monolith lasted through 10 years of explosive growth at airbnb. Thats a pretty scalable to me.

FTA it sounds that it wasnt he language of framework that was an issue, but rather the monolith model.

link
yftsui 981 days ago
Well, you have to put the human cost investment into the picture. When the cost to develop/maintain becomes significantly high, it’s a natural choice to deprecate it and move on to something faster.
link
viraptor 981 days ago
It scaled for a long time for Twitter. With few exceptions, we're not going to work at anything close to the scale of Twitter at the time, so that's plenty scalable for most use cases. Now, if you want to be more compute-efficient that's a different question...
link