Github Scaled for Rails

You're building a new business, and dammit, you already know you need to scale! Rails is your go-to framework. It scales! Sure, Ruby is 5x slower than other interprited languages. Sure, it's 3-4x the hosting costs because of this. Sure, Rails doesn't support event driven architecture, so you get much less bang for your buck for each request thread. Sure, Rails is so slow for Shopify that they scale up by making entirely new pods (of shit) to "scale" horizontally. Sure, no one on your team knows what "static analysis" means nor why it's important. Sure, your tech lead unironically thinks method_missing is an elegant method with valid use cases. None of this reality matters to you, though, because Github uses Rails, and boy did they scale! Rails scales, folk. Github has no problem with it!

First off, Rails was too slow for Github, so they forked it. (5:59). Err, yikes? Their fork diverged so much that "it was Rails morphed into a different framework." (6:50). Ok, Rails was so slow that Github forked it and no longer called it Rails. But who cares? The core Rails project was still developing and getting better every day. Github switched back to the improved Rails, right? Well, no, they avoided it, because "Rails 3 requests were up to twice as slow as Rails 2" and "ActiveRecord in Rails 3 was found to be five times slower than Rails 2" (7:14).

OK, but no problem! It doesn't matter that Github didn't want to use slow, laggy Rails. Eventually Rails got a little faster, and Github switched off their fork to Rails 4. And Rails upgrades are easy! No one has ever struggled with them. Any Rubyist worth there class << self define_method(:salt) will tell you that all you need is a good test suite. With tests, software upgrades are trivial and safe. Meta whatgramming?

So it's no surprise that this speedy, easy upgrade took Github four+ engineers six months (9:38) to get off the fork onto Rails 3. Err, didn't we say Rails 4 was out at this point? Whatever!

It then took Github 1.5 years to upgrade from Rails 3 to Rails 4 (11:36). And then getting onto Rails 5 took "only 5 months with a larger team." Overall it took 10 years for Github to get to modern releases of Rails.

This is your company, right? You need to scale, so you can afford to dedicate burnt-out teams to Rails upgrades for months to years. Hell, you'll probably even write a completely non-self-aware blog about how you only spent a year not delivering features so you could upgrade Rails. Sure, a language with any kind of type system makes significant upgrades take days to weeks, not months to years. But that's irrelevant, because Github wasted so much time upgrading Rails, and Github scales! And so can you!

Actually, maybe it doesn't matter to you at all. Rails upgrades are so notoriously shitty that an entire cottage industry has formed around ensuring security patches are ported to your already-outdated Rails version. Why pay your engineers to burn out when you can literally pay for tech debt?

OK, fine, many large companies burn years of engineering hours into the ground upgrading Rails. Sure, this problem doesn't exist in other ecosystems. Who cares? Github has scaled, it continues to scale, Rails obviously scales, it's right for us!

Rails upgrades were so painful for Github that they now work directly off the Rails main branch. Github effecively subsidizes Rails development by contributing back to upstream. Github has built teams and entire systems specifically around staying up to date with Ruby and Rails. Github employs core Ruby and Rails maintainers to help tune the and build the system. This is bafflingly high overhead and processes to work with Rails.

I'm describing your company, right? You need to scale, so you can afford to build a Rail main branch CI pipeline. You can afford years of Rails upgrades and LTS costs. You can employee core framework team members to subsidize the build of the open source frameworks you use.

I mean yeah, Github can afford lots of overhead for to keep using their favorite toy. But Rails (which, again they didn't use), was definitely the right choice for Github when they started out. Just listen to Github co-founder Tom Preston-Werner champion it: "Rails started to feel like a lot of magic. When we founded Github, I was growing tired of Rails" and "I was not enthusiastic about how that magic and complexity creeped in", which he lists among "reasons I don't use Rails anymore" (12:07). Uhhhhhhhhhhhhhhh.

If I'm describing your company, then yes, by all means, you can unironically say "Rails scaled for Github" in the same breath as your recommendation to use Rails. If I'm not describing your company, then

def rails
  def rails
    "Don't"
  end
  "use Rails"
end

> rails
"Don't"
> rails
"use Rails"