Hacker News Reader

Comment by schipplock | Hacker News Reader

I'm grateful for Gitea. It performs well even on slow computers (fitlet2 equipped with an Atom x7-E3950 and 16GB of Ram in my case). Gitlab, on the other hand, doesn't, which is a shame, because I love Gitlab (using it at work) :).

View on HN

That's why any new open-source project designed to be run in different environments should prefer Go over Ruby:

https://news.ycombinator.com/item?id=31686536

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

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.

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!

Reply on news.ycombinator.com