Why We're Sticking with Ruby on Rails at Gitlab

Performance is indeed worse. We're moving the 20% of the app consuming 80% of the compute to Go. For example with Gitaly https://docs.gitlab.com/ee/administration/gitaly/ BTW This also enables reuse, Hugging Face recently started using Gitaly https://discuss.huggingface.co/t/announcement-switching-our-...

Performance is one thing, the hill a contributor must climb is another; I've taken a swing or two at trying to fix some of the 43,000 issues and in my opinion if RubyMine has no idea what's going on with your codebase, maybe you have a problem

they recognize it. It's in the article, even.

Whether they have to act on it? Maybe not.

Almost all of Rails codebases that I worked on, had performance problems (in that it was hurting the bottom line). But most often, the solution was found elsewhere: tune the database, use AR smarter, spin up more servers, buy a bigger database server, etc.

I don't know much about GitLab's code, but in my experience, language execution speed is one of the very last things you look for when optimizing the performance of a web application. The odds are overwhelmingly higher that the problem exists at the database, redis, API interaction, e-mailing, or 1,000 other things before rewriting in a faster language would be advantageous. Even then, it's often more cost effective to throw more servers at the problem. Web and worker servers typically scale horizontally effectively.

I like it that you know better than they what to do and kidna ignore the whole article, you sound like executive material.

Performance of Ruby is pretty darn good tbh. Performance of Rails is another question tho.