Comment by nurettin
Comment by nurettin a day ago
The entire 2012 scene used Rails. Then they realized it was hard to scale and rewrote everything in Go.
Comment by nurettin a day ago
The entire 2012 scene used Rails. Then they realized it was hard to scale and rewrote everything in Go.
Rails has been around for time to change the calculus on it too. It came out in 2004. The smallest instances you can get today on AWS would have counted as fairly powerful servers back then (with insanely fast CPUs), and by the second or third smallest you're beyond anything available at the time, and there's still room to run after that.
Even the slowest web frameworks running on modern hardware take some quite substantial load before they're a problem. It's good when choosing a framework to consider if you're doing stuff where that might be a problem, but it's also good not to overestimate the performance needs for your site.
Twitter also would've scaled a lot further on Rails just by dismantling the monolith. I don'tike Rails (though I love Ruby), but the way Rails was scapegoated for an original architecture that was not suited for scale irrespective of framework or language was annoying.
Yep totally agree. And also realistically once we hit that kind of scale it was perfectly reasonably to start looking at other options as well.
It's been a while but I think we were at like 250mm MAUs when we finally decided to break up the rails monolith (and I think it was still on Rails 3 at the time, but don't quote me on that). The number of companies that ever hit that kind of scale approaches zero, and even less in the B2B space.
The rails doesn't scale trope is pretty old at this point and has largely been discredited. Don't believe me, take a look at Shopify or Github.
That makes perfect sense for people that need to scale. But doesn't explain why newer start ups aren't using it.
Doing things that don't scale is a proven strategy at the beginning, pg even has a post about it
Ruby has static type system built into the language.
There are others you can use if you like.
I think a much better way forward is proposed by Jake Zimmerman[1] of the Sorbet team. That is to allow the runtime to parse RBS inline format comments.
That retains Sorbet’s fast static checker and its runtime checks which Typescript compiled to JS lacks.
steep and rbs don't work so well and are the wrong approach. sorbet is also the wrong approach but it works better. The Python 2 -> 3 way would've been a better way to do it but Matz chose an unwise way (separate files) that doomed it combined with a failure to type all the things and make it work. Oh, and very few Ruby gems are cryptographically signed and so most code is mostly untrustworthy. Making important things optional makes them unused and essentially worthless.
All of these problems are worse in javascript.
> a failure to type all the things and make it work
Everything is typed in Ruby.
> Then they realized it was hard to scale
A rumor perpetuated by exactly one company - Twitter. I know because I was there when it happened and helped dismantle the original monolith.
Rails scales just fine for 99%+ of business cases. If you're doing a sustained 5k writes per second with bursts up to 100k...sure maybe you need something more specialized.