[coldtea]

I mean, their original setup during early years (and I'm not making this up) required them to restart their Rails service every day, else it would crash/stuck because of memory leaks.

That's not a "tech startup" based on "hardcore engineering", that's a startup based on a social idea and implemented with some trivial tech.

Scaling this to hundreds of millions is not exactly a "hardcore engineering" thing either. Mostly regular engineering with some good practices (like share nothing) and devops. Tons of companies do just the same, today you can even do it from your bedroom by building on top of AWS, GAE, etc, there are even templates for this...

[sciurus]

I think you're dramatically underestimating the scope and scale of the problems Twitter had to solve. See the thread below for examples of the sort of solutions they had to build because open source or cloud-hosted solutions weren't available or viable.

https://mobile.twitter.com/danluu/status/1592774269733601281

[bydlocoder]

Do you think they still run Ruby that can't reclaim allocated unmanaged memory? Do you have any idea how their stack looks now?

[coldtea]

>Do you think they still run Ruby that can't reclaim allocated unmanaged memory?

No, I don't.

My point is their initial success years (which wasn't that off the current product) wasn't some hardcore engineering feat: just a cruder-than-average Rails app.

Whatever their stack looks now is irrelevant.

[tekstar]

Around 2012-2015 we had someone on-call over the holidays do a redeploy every few days because of Rails memory growth at our now-IPO'd ecommerce giant.

This growth impacted every rails app back then, the popular ones more quickly is all..