Hacker News Reader

Comment by thayne | Hacker News Reader

I suspect the fact that Github and Gitlab use ruby backends is a significant (although by no means the only) factor in the slowness of Github and Gitlab. So yes, being written in a language that is better suited for high performance at scale is, potentially, an advantage. Although if it is vibe coded, there's a decent chance there are architectural problems that offset the advantage gained from the choice in language.

View on HN

GitHub used to be great when the frontend too was in ruby, the react rework might've got somebody promoted but performance was never the same.

GitHub is so data heavy and there's so little reactivity that it should really be server side rendered.

The frontend was Ruby?? Are you sure?

Not literally. And I would hardly say it was a matter of language superiority. I love Ruby myself. But Github was a lot simpler when it was still just a Rails app.

But Rails was SSR by default, and most of the frontend was just Embedded Ruby (ERB) template files all over the place. And way back when, it was even relatively common to use Javascript supersets like CoffeeScript[1] and Opal[2]. The latter being Ruby that compiled to JS.

[1]: https://coffeescript.org/ [2]: https://opalrb.com/

Yes, standard rails. Rails does not ship with components out of the box and the most prominent component system for rails was built and is maintained by GitHub. They have been moving to React for the last few years though, it seems to be more about hiring and ergonomics rather than capability.

As in rendered server-side.

Reports of Ruby slowness are often exaggerated. Around the time GH was built that was certainly true, but in the ways that matter Ruby is more than fast enough nowadays, even at scale. (Shopify is a rails monolith, as is intercom and a bunch of other massive services) Compute is/was pretty cheap and the economics of ROR mean that it's ultimately not that expensive to run. I think GH's slowness is a mixture of mismanagement and issues on the frontend.

But for sure a systems language is going to be far faster on paper and Rails is far from perfect and does have some performance foot guns you need to avoid. And yeah, architecture is everything.

Reply on news.ycombinator.com