Hacker News Reader

Comment by nurettin | Hacker News Reader

The entire 2012 scene used Rails. Then they realized it was hard to scale and rewrote everything in Go.

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

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.

Nah. If anything it's NodeJS that ate Rails' lunch. Around 2013/2014 it took over as the defacto default stack for startup.

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.

It scales just fine. AirBnB, Github, and Shopify use it.

It does now, but it took a few years for rails to do what nodejs did when it came out (the live chat demo app).

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

https://www.paulgraham.com/ds.html

> But doesn't explain why newer start ups aren't using it.

Plenty of newer startups use Rails. At least several pretty much every YC batch. You just need to pay attention.

No static typing would be a good dealbreaker for us.

Ruby has static type system built into the language.

https://github.com/ruby/rbs

There are others you can use if you like.

Unusable mess.

Ruby should take lessons from Python and TS on how to make proper gradual typing.

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.

1. https://blog.jez.io/history-of-sorbet-syntax/

It should stay true to itself and not do it at all.

Sigh - all languages needn't converge into Grey Goo.

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.

Reply on news.ycombinator.com