Hacker News Reader

Comment by andyjohnson0 | Hacker News Reader

Github used to be built on mysql / redis / ruby on rails / C / shell, running on dedicated hardware. Microsoft left it like that after they acquired the company.

Eventually, though, they decided to migrate the whole thing to Azure. And they were far enough through that to be basically committed... when AI coding started hitting them with much higher workloads.

I personally think the reliability problems are more to do with the reliability of the Azure migration. But both factors are likely relevant.

View on HN

They didn't leave the architecture alone, right? They shoved React in and created a weird SSR + React frankenstein that is objectively worse in many ways.

React apps with SSR is standard these days.

SSR that is javascript native, sure. This is still Ruby doing the rendering.

What's the difference? If it's SSR it's happening on the server, the only benefit of using JS is ergonomics. Ruby is fine otherwise.

Ruby can't render React code. JavaScript can. With GitHub it seems that they sometimes can do SSR for the React bits, but that must mean that they're invoking a JavaScript interpreter within the Ruby process. Which means they have the overhead of two runtimes and the jank that comes with the IPC between the two.

It's just pointless hacks on hacks. GitHub didn't need React on the frontend and any potential resource savings of client side rendering were lost when they realized they need to do SSR on that stuff too.

I've encountered so much frontend jank as they expanded that portion of the stack whereas it was always excellent when it was just Ruby SSR and minimal JS on the frontend.

Wish they spent some AI tokens on that abomination to fix at least some of the countless issues it has, because their human engineers definitely won’t.

And yet, the React/SSR infra has never gone down.

Well, maybe not completely down but the amount of navigation issues, screen flickers and unhydrated stylesheets I have everyday is not something I'd expect from such a product.

This is the reason, at least what I know from people who worked there, the azure migration has been very painful as far as I’m aware

yep this was the same with LinkedIn who killed the migration after massive massive costs ~ https://www.theregister.com/on-prem/2023/12/14/microsofts-li...

Oh I’m adding that one to my mental list of Microsoft failure

After their infamous "Fail Whale" outages, Twitter replaced its Ruby on Rails / MySQL stack with modern (at the time) technologies: Scala (functional language running on the JVM) / Finagle (RPC) / Thrift (framework) / Kafka (message queues) and this made Twitter stable under the load of several hundred million users.

Ruby is single-threaded, slow with poor GC and memory leaks. As Twitter's Alex Payne said publicly in 2008: "there shouldn't be doubt in anybody's mind that Ruby itself is slow" and that scaling Rails meant "just throw more instances at it"

tell that to Shopify that handles 8.15 million requests per second and processes 5.1 million per minute in sales during Black Friday. You scale your architecture, not your programming language.

Current Rails and Co are miles away from where they used to be then, but even then my feeling was that maybe it was the skill/culture/dev ops at Twitter that was at least partly responsible for the fail whale. But I don’t have any insight as to what was actually going on inside before and after that transition.

It’s 2026 and we’re still benchmarking Ruby using Twitter’s 2008 architecture. It was less about a language choice and more about years of architectural redesign. I thought we were past this by now.

Ruby (language) on Rails (highly opinionated framework) is both a language and an architecture.

Reply on news.ycombinator.com