[nindalf]

Rails was a great choice for Shopify, GitHub and Stripe, no doubt. No one is questioning that.

GP’s sarcastic “rails doesn’t scale” implies that it would also be a great choice for people starting afresh in 2023. The reply asks for a comparison with other languages popular in 2023, especially ones that are known for being more performant (lower memory and CPU consumption, lower latency).

And that’s when you’re dragging the conversation back to 2006. It’s not 2006 anymore.

[stevebmark]

Rails was initially too slow for Github, so they forked it, didn't use "Rails" for a while [1], lost literal engineering years to upgrading it (same for Shopify), and now Github has an engineering department dedicated to working of the Rails master branch directly, which is huge engineering overhead and a problem and solution that shouldn't exist. Github co-founder Tom lamented using Rails at Github and has stopped using it [2].

If you're Github or Shopify and can throw (waste?) engineering years at solving a framework specific ecosystem nightmare problems, and have the klout and runway to hire core Ruby and Rails maintainers, then you're probably in a highly unique situation and could use any framework you want.

The rest of us don't see Rails as a great choice for Github. Doubt and questioning.

[1] https://videos.itrevolution.com/watch/550704376/ [2] https://youtu.be/GfhPeOiXDLA?t=725

[byroot]

> Rails was initially too slow for GitHub, so they forked it, didn't use "Rails" for a while

That's a weird way of framing it.

They stuck with a fork of Rails 2.3 for a long time because the upgrade was deemed too costly, not because their fork was faster.

In the end their performance patches were either outdated or contributed upstream, and they are now on Rails main branch.

And while it was a fork, it was still largely "Rails".

[stevebmark]

Please listen to the Github engineers in the provided links.

> We forked rails and _practically wrote our own._ We fought against the framework. We deviated from the framework, and we even wondered if rails was right for us at all.

and

> Rails 3 was found to be five times slower than Rails 2

[byroot]

> Please listen to the GitHub engineers

I regularly talk with engineers that worked on that project at GitHub, some are now my coworkers. I know more about this effort than what was said publicly.

> Rails 3 was found to be five times slower than Rails 2

This is a bogus claim. It might have been 5 times slower on some pathological cases, it absolutely wasn't 5 times slower overall.

[stevebmark]

The presentation and "bogus claim" is from a principle Github engineer and core Rails team member. I will trust them rather than anonymous anecdotes.

[byroot]

I'm a Rails core member too, and Eileen is my colleague...

You are interpreting both links you gave in terrible ways.

[nindalf]

Yes, not ideal. But we can’t know what would have happened if they had chosen a different language in 2007. Did they have the option of an efficient, well supported language that continues to be used in 2023? Maybe Java, although Java languished for years before development picked up again. C# is also a candidate.

But one thing we can’t measure - how many candidates chose to join Shopify and GitHub because they were keen to work on Ruby? Java had a reputation for being boring, while Ruby was fun and exciting. Their success was possibly tied to this, but we’ll never know for sure.

In 2023 the calculus of what language to choose is different. But these companies are just glad they succeeded while others didn’t.

[gloryjulio]

The problem is at the time if you want things done fast, Rails was the right choice. Almost no startup would touch Spring as app server at the time. Django had not reached 1.0 yet, and it's not faster anyway. So for a startup, Rails was the only realistic choices.

[reducesuffering]

What I find ironic was that in 2006, Rails was the shiny new kid on the block. These co's picked the "new" way of doing web dev compared to the stodgy Java/C# types. And yet, by recommending Rails for a new startup in 2023, they're actually more like the stodgy Java/C# old school paradigm camp, that the Rails startups avoided! A startup that would've used Rails in 2006 is more like a startup that is using things like NextJS in 2023. We see that in the stacks of new YC companies

[ericb]

The NextJS folks and Go folks are in that sweet spot. You use the framework du jour, you pat each other on the back, beaming with the folly of your ancestors to use such inferior tools, thinking "this is a golden age of NextJS (or Go) that will surely never end."

What comes next might not even be better, but that won't matter, because what came before won't be cool anymore.

You die a hero or live long enough to become the villain.

[gloryjulio]

Nextjs is not comparable. I'm not sure if it's required to get some web pages out, I don't think frontend is that important in the startup space any way if u are able to fulfill the requirments

For app server nowadays u have many choices. But 15 years rails was really the only better choice for a few men's startup shops. C# was on windows shop, that's a no for many

[chucke]

You're implying that those languages made actual building products easier. I think we know by now they didn't. Go is a language which preaches building your boilerplate than reusing it. Produces very little of the economies of scale requires to build compelling products. It has other advantages, and the single binary thing captured a niche in infrastructure software, but that's it outside of Google. Rust is still young, jury is out, but it's already considered a big and hard to learn language, and that's not going to change soon. It'll eventually find a niche.

Ruby is still a great way to start it up. Consider that in 2006-2008, it's deployment story was horrible. Since then, the ruby ecosystem bootstrapped lockfiles, 12 factor app manifesto, and a lot of the conventions we all take for granted nowadays. And while there are certainly enough arguments to bikeshed on, its still a rock solid ecosystem.