4 ms·

Why We're Sticking with Ruby on Rails at Gitlab

10 points by Umofomia 4y ago

CameronNemo 4y ago
Performance of Ruby is often terrible. At some point GitLab will have to recognize that. I know they have some Go in the stack, but so much is of the application is hinged on the Ruby monolith.
- sytse 4y ago
  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/ 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-git-infra-to-gitaly/15030 https://discuss.huggingface.co/t/announcement-switching-our-...
- mdaniel 4y ago
  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
- berkes 4y ago
  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.
- ryanbrunner 4y ago
  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.
- weatherlite 4y ago
  I like it that you know better than they what to do and kidna ignore the whole article, you sound like executive material.
  - CameronNemo 4y ago
    1. Not an article, an ad 2. I didn't ignore the whole article, the article ignored my concern save for a few sentences.
- iamsandelius 4y ago
  Performance of Ruby is pretty darn good tbh. Performance of Rails is another question tho.

10 points by Umofomia 4y ago

Performance of Ruby is often terrible. At some point GitLab will have to recognize that. I know they have some Go in the stack, but so much is of the application is hinged on the Ruby monolith.

sytse 4y ago
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/ 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-git-infra-to-gitaly/15030 https://discuss.huggingface.co/t/announcement-switching-our-...
mdaniel 4y ago
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
berkes 4y ago
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.
ryanbrunner 4y ago
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.
weatherlite 4y ago
I like it that you know better than they what to do and kidna ignore the whole article, you sound like executive material.
- CameronNemo 4y ago
  1. Not an article, an ad 2. I didn't ignore the whole article, the article ignored my concern save for a few sentences.
iamsandelius 4y ago
Performance of Ruby is pretty darn good tbh. Performance of Rails is another question tho.