← Back to context

Comment by jeremyjh

5 hours ago

The Ruby on Rails tax. It isn’t impossible to make snappy apps with it, but it must be uneconomical in terms of dev costs because no one does.

While there is indeed a Ruby on Rails tax, Github is also written in Rails as well (https://github.blog/engineering/architecture-optimization/bu...)

So is Shopify and Stripe. They can scale.

These days, if I want something that has some of the ergonomics of Rails in a platform I know can scale better than Ruby, I reach for Elixir/Phoenix.

  • Github can get pretty sluggish as well; if you have a pull request with lots of comments page loads begin to take a dozen seconds or more. AI code review bots make it painful for humans to use it.

> The Ruby on Rails tax.

Yeah, from my experience administering a pretty small self-hosted instance, I think it's got to be this. Every single admin action you try to take on the backend is SLOWWWWW. Restarting the services takes a few minutes. Just to bring up an admin console on the server in a CLI takes well over a minute, which indicates a tremendous amount of overhead purely on the ruby side.

There's just something fundamentally slow about how it's all put together. I wouldn't blame the language or tech stack, exactly - but perhaps Ruby on Rails is not a great fit, anymore, for a fully featured forge of this scale?

I dont think that is true, consider Fuzzy, Hey, Basecamp, Shopify all seems to be doing fine. Shopify actually got impressively fast in the recent two years I have no idea why. Github used to be fast as well.

So while Go by default will always be faster then Ruby Rails, there are plenty of examples of decently fast Ruby Rails Apps. Having 10 years saying they will improve performance and not getting any of it suggest problems with Gitlab itself more than RoR.

  • > consider Hey, Basecamp, Shopify

    Basecamp is slow as hell, Shopify depends on some insanely specific tuning, and I don't use Hey but it's the same team as Basecamp IIRC.