3 ms·
Ruby, compared to some compiled languages, is indeed harder to ship, which is why we've got the gitlab-omnibus package.[1] Thanks to our packaging team the inst
by zegerjan 10y ago
Ruby, compared to some compiled languages, is indeed harder to ship, which is why we've got the gitlab-omnibus package.[1] Thanks to our packaging team the install and getting GitLab up and running shouldn't take over 10 minutes. Maybe not as easy as compile and run like Go offers, but I urge you to try it, it is really simple.
Now, we use more and more Go within GitLab. For example, gitlab-workhorse[2] and the gitlab runner[3] are written in it. But converting our main app, gitlab-ce and gitlab-ee, to another framework and language would makes us unable to ship new features for at least a year. Even when we would gradually rewrite this would hurt our ability to consistently ship new great features.
Also, please don't forget that Ruby and Ruby on Rails are very mature, stable, and so far have served us very well and I expect it will for the next years.
We might, as we've been doing for some time, let workhorse handle more compute expensive operations, but again, other than that I don't see it happening any time soon.
[1] https://gitlab.com/gitlab-org/omnibus-gitlab https://gitlab.com/gitlab-org/omnibus-gitlab
[2] https://gitlab.com/gitlab-org/gitlab-workhorse https://gitlab.com/gitlab-org/gitlab-workhorse
[3] https://gitlab.com/gitlab-org/gitlab-ci-multi-runner https://gitlab.com/gitlab-org/gitlab-ci-multi-runner
- sandGorgon 10y agothanks! makes a lot of sense. I asked because 20 mil buys a lot of developer hands to make this happen.
- Singletoned 10y ago> converting our main app, gitlab-ce and gitlab-ee, to another framework and language would makes us unable to ship new features for at least a year This would be quite a good argument for not tying oneself so deeply to a particular framework.
- matt4077 10y agoWhat? How would a transition to go be easier if they had used ruby without rails?