Hacker News Reader

Comment by stevebmark | Hacker News Reader

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

View on HN

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

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

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

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

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

You are interpreting both links you gave in terrible ways.

I’m quoting, not interpreting. What am I missing?

It sounds like you’re seeing the pain GitHub suffered through rose colored glasses. The talks about GitHub Rails upgrades say it took years and caused burnout.

You are quoting out of context, losing the meaning of the quotes.

The conclusion of Eileen's talk is that by not following with upgrade and essentially forking Rails 2.3 they painted themselves in a corner. They took short term gains, and produced longs term losses. It's a self induced problem.

In the end they upgraded and are now tracking the main branch, so the problem wasn't Rails.

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.

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.

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

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.

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

Reply on news.ycombinator.com