It's... ok. But many of the really useful features are paid. E.g. merge trains or mandatory reviews.

I also don't think "it's open source!" is a huge differentiator because it's enormous, difficult to deploy from source and written in Ruby so the chance of being able to actually modify it for some feature you want is near zero.

I think Forgejo is probably a way better option at this point even if it is less mature. It's written in Go so way easier to deploy and edit. And none of the features are paid.

I do like Gitlab but... it's not amazing. I liked Phabricator more (except for its lack of integrated CI).

▲

quesera 6 days ago | parent [-]

> written in Ruby so the chance of being able to actually modify it for some feature you want is near zero

That's a silly thing to say.

▲

IshKebab 6 days ago | parent [-]

It isn't. Ruby lacks static typing, and Rails heavily uses generated identifiers, which means navigating a huge codebase like Gitlab is basically impossible unless it's your full time job (or you get lucky). I've tried. I kept finding methods that - based on a grep - were never called from anywhere, and there's no IDE support for something like Find All References.

I'm sure if it was your full time job you'd eventually learn the codebase, but there's no way you can just dip in and add a feature unless you really persevere.

But I did manage to add a few features to the gitlab-runner (used for CI) - because it's written in Go, and Go has static types and pretty great IDE support these days. Night and day.

I've also added a few features to VSCode which is a similarly huge codebase. Again it's written in Typescript which has static types and good IDE support. It would have been effectively impossible if that wasn't the case.

▲

quesera 6 days ago | parent [-]

This does not match my experience at all, and I think your "near zero" claim is silly.

> difficult to deploy from source

I won't argue with you here. There are a lot of moving pieces in a Rails deployment. This isn't different from most web app frameworks, but it is difficult.

That said, I've never worked on a Rails app where deployment was any more difficult than a variation on `bin/deploy v123 production`, because I wrote that script and it works 100% of the time.

> and written in Ruby so the chance of being able to actually modify it for some feature you want is near zero

But this is still silly. You just don't know Rails or Ruby well, and don't want to learn them. Fine, but if you hadn't already made that decision, you would find the solution simple enough. No judgement intended -- different framework/language paradigms fit different people differently.

Rails has great IDE support also. Static typing can be a useful language feature, but a lack of same has not ever, in my experience, made it more difficult to understand real-world code.

There is a lot to love about Go too, don't get me wrong. But I would guess that the number of random developers who could drop in and be immediately productive in a Ruby/Rails app, vs a Go webapp, is basically equivalent. The overlap of projects where both would be highly appropriate choices is a bit thin.

[I hire into Ruby/Rails jobs regularly. I often hire senior developers with no Ruby/Rails background, but I do not hire people into these positions who are not open to learning. It takes a senior dev (from the C/Algol family) one day to learn Ruby, and (from a web dev background) a week or less to learn Rails. I have never seen a failure.

I also hire into Go jobs almost as frequently. The hiring criteria is a bit different (less emphasis on web awareness), but I do find it easier to teach Go to a Ruby dev, than Ruby to a Go dev. Make of that what you will.]

▲

mdaniel 6 days ago | parent [-]

I am not trying to start trouble, or a heated debate, but I did want to say that my experience was the same as OPs and I am also coming from a static typing background so that likely explains my having a similar experience and expectations. I did for sure use RubyMine for attempting a change, so not "vim and yolo" but rather world class tooling and trying to discern where any random symbol came from was oppressively hard

That's not even getting into attempting to use their "happy path" <https://gitlab.com/gitlab-org/gitlab/-/blob/v18.2.1-ee/.gitp...> -> https://gitlab.com/gitlab-org/gitlab-development-kit#local which I found just incredibly challenging getting it to use my copies of the repos. But, just like in every one of these conversations, it's been a number of years since I tried it so maybe it's much better now

▲

quesera 6 days ago | parent [-]

I wasn't either, believe it or not! :)

But I was responding specifically to "in Ruby, so the chance of being able to actually modify it ... is near zero", which does not address the real issue.

It's perfectly possible to write simple, clear code in Ruby (and Rails!), but I'll concede that GitLab is not the best example of that.

If OP had said ~"... and the GitLab codebase is large and can be difficult to navigate and make drop-in contributions to ... also I have an aversion to dynamically-typed languages" :) ... then I wouldn't have bothered commenting.

▲

IshKebab 5 days ago | parent [-]

I have an aversion to dynamically-typed languages because of these problems. It's not some random preference.

> You don't want to learn Ruby or Rails

Learning Ruby or Rails wasn't the problem. The Ruby language itself is fairly trivial. The issue is the lack of static types, and the fact that you can't even fall back to grep.

I know Python very well but it is almost as difficult to edit large Python codebases with no type hints. (It's not quite as bad because most Python code is greppable.)

	▲	quesera 5 days ago \| parent [-]
		Ruby and Rails work perfectly well for many many people, and you have chosen not to be one of them. That's a valid choice, but it's your choice and nothing more. It really isn't much about Ruby or Rails. I grep through Rails code bases all the time. It is my first-choice method of discovery. In the very rare cases where it does not work immediately, I set a breakpoint and run from the REPL. This never does not work, even in the GitLab code base. I have my criticisms of Ruby, and Rails, too. But your "near zero" comment is a shallow dismissal that captures your biases and presents them as some kind of informed truth. It is not.