I think the issue with Gitlab resource usage isn't the application itself, but the sheer complexity of Gitlab and the amount of services needed to run the whole thing. It even starts Prometheus and Grafana and stuff like that. https://docs.gitlab.com/ee/development/architecture.html

Yes, it is mostly ruby if you profile it.

Is it possible to run it under one of the supposedly-faster alternative implementations like TruffleRuby?

In general, the larger the project the more likely that all obscure corners of a language are utilized somewhere in the project; these same obscure corners are typically the weakest point of alternative implementations and are likely to cause issues.

Nah, it's definitely Ruby. It uses Postgres + Redis + a S3-like object store for most of the data heavy-lifting. There is some additional ops complexity in Gitaly, their git backend, but that wouldn't be a huge source of resource usage in a simple setup

I'd say that an open-source project has a (much) longer horizon than a typical for-profit startup. The startup needs to iterate incredibly quickly, to adapt to the market and capture it, before the money runs out. Then it is usually acquired, and the code base becomes someone else's headache. It can even be rewritten wholesale, how it happened to Twitter.

A typical open-source project is written by its users; if you want a feature, contribute, don't demand. The project can (but not always does!) choose tools that are best in long term and fit the problem domain better, even if they require time to get started / involved, and longer to get an MVP out the door.

Go checks both boxes: it lets move fast, but also is a reasonable long-term choice. I used to shy away from Go-based projects, but after 1.18 I have to admit that Go becomes acceptably pleasant to use!

Nah, the issue with the resource usage of Gitlab is not caused by Ruby. It is the architecture they chose. You could build the same resource hog in Go if you wanted to.