It works incredibly well in my experience. There are two main pain points.

First is related to certain projects not really following the rules: grpc-go and Kubernetes. grpc-go in particular has caused lots of headaches due to removing APIs in minor releases. Kubernetes has had a crazy build system that preceded Go modules, so maybe it will get better over time.

The second pain point is around managing multi-module repositories. It kinda works by using replace directives but it’s pretty hacky, to the point where I’m actively avoiding using multiple modules in projects even when it “should” be a good fit. There’s a proposal on the table to add workspace support to the go command that might make this work better.

Overall, despite these pain points, it’s easily the best package manager I’ve used. It’s simple and predictable.

Minimal Version Selection itself is fine, in my experience neither better nor worse than what I guess is the de facto standard of… Maximal {Patch, Major} Version Selection? It biases for churn reduction during upgrades, maybe, which at least for me doesn’t have much net impact on anything.

But a lot of the ancillary behaviors and decisions that come with MVS as expressed in Go modules are enormously frustrating — I would go so far as to say fundamentally incompatible with the vast majority of dependency management workflows used by real human beings. As an example, in modules, it is effectively not possible to constrain the minor or patch versions of a dependency. You express module v1.2.3 but if another dependency in your dep graph wants module v1.4.4 you’ll get v1.4.4. There is no way to express v1.2.x or v1.2.3+. You can abuse the require directive to lock to a single specific version, but that constraint isn’t transitive. And module authors can retract specific versions, but that power is not granted to consumers.

edit: for more of my thoughts on this exciting topic see Semantic Import Versioning is unsound

I think it’s just the bees knees. At this point I’m irritated using anything besides MVS. In practice, it does exactly what I want, dependencies get updated at a decent schedule (and I can always force them to update myself), and everything has a layer of predictability that is lacking in other systems. It’s too bad that it took so much drama to get to this new optimum state but I’m glad Go pushed through with it and hope more systems adopt MVS soon.

Honestly, it makes me wonder what other local optima need to be re-evaluated with a fresh perspective.

I use Go a lot at work, and honestly while the MVS makes me incredibly uncomfortable, I haven’t had a ton of problems with it. I’m not aware of any CVEs/security issues for our deps, but it’s very possible that some are lurking in our products and will stay there. I also haven’t run into bugs in transitive deps that have caused issues, but again, it’s something I’ve worried about.

However, because of these fears, I have tried to use go get -u -t to update all my deps and that typically always breaks. Between subtle backwards incompatible-changes that modules have snuck in and repository renames, usually trying to upgrade all my deps breaks in some way.

I don’t think Go’s approach is really that unusual: the conventional wisdom in other ecosystems is that you should always use a lockfile, so dependencies are already version-locked and upgrades have to be performed manually.

The only new thing Go does is, in an oversimplified description, that it synchronizes the version lock of direct dependencies back from the lock file (go.sum) to the dependency declaration file (go.mod). If you use the CLI to manage dependencies, you’ll barely notice any peculiarity.

MVS is also not a very radical idea. What it does is restricting version constraints to only one operators, ≥. It does not need more operators because Go requires backward-incompatible versions (“major versions” in semantic versioning) to be effectively different modules. This means that a module is expected to maintain backward compatibility, so you only need ≥. If the module developer accidentally broke backward compatibility, the expectation is that they’ll fix it shortly, and the few incompatible versions can be manually marked with the exclude directive.

For the record, MVS is more or less what Clojure’s deps uses as well. I think there are two things that makes MVS pretty good in practice:

• MVS is predictable and easy to understand. If you ignore the I/O part, you can implement the algorithm itself in less than 50 lines (… depending on language).
• By stating that MVS is the standard, library authors now have to/feel they have to enforce that for their libraries. This means minor version changes don’t tend to contain breaking changes, and since major version bumps are new package altogether, upgrading tends to be pretty painless. There are some exceptions that proves the rule though (grpc-go, what are you doing?)

I think the latter is the most important aspect: Library authors seem to care about backwards compatibility much more than they used to. That automatically makes upgrading easier, regardless of the dependency algorithm.

One problem with Go’s dependency management (but not really MVS) I experience now and then is the entire “built on top of Git(Hub)” issue: Sometimes libraries and programs can just disappear.

The worst part of that aspect is the case where you depend on a library, found and resolved a bug, and need to use that version before it’s merged into the upstream repository. In those cases, you’re left with two options:

1. Depend on your PR’s latest commit on the upstream repository, and hope the library author doesn’t rebase or squash the PR. If they do, your builds will break because the commit doesn’t exists on a branch any more.
2. Depend on your own commit in your own fork, then remember to switch back to the original repository when the PR has been merged (if you’re able to remember it).

i.e. you have to pick between potentially failing builds or potentially stale dependencies. Granted, I don’t think this is worse than what other dependency management solutions do, but it’s a trap that I’ve fallen into a couple of times.

I’m largely in agreement with what Peter has pointed out in a few other places in this thread - talking about MVS often isn’t that helpful, so much as how some of its requirements, and the poor assumptions they’re based on about how software gets written, amplify out into tooling. I won’t rehash those points, but will instead try to focus more narrowly on MVS itself.

MVS has turned out pretty much as i expected. Its best feature is its predictability, as others have pointed to in this thread. It’s not the first version selection algorithm to be predictable/avoid NP-hard search - Maven’s had already been around for years before MVS, and there may be other, older ones in this family of which i’m unaware. Maven makes a different tradeoff - “rootmost declaration wins,” vs. “largest version number wins” in MVS.

The scenario i was most concerned about was a social one: that the baked-in premise of “maintainers are expected to promptly adapt to the inevitable, unavoidable changes-that-break-them in their dependencies in order to keep MVS’ assumptions true” would become justification to pile onto maintainers even more and demand free labor from them. That hasn’t happened AFAICT, and in retrospect, it seems a bit silly to have been so concerned about it. (I was feeling quite momma-bear, wanting to protect the community from the same kinds of “use you for your labor then discard you” feels i was in.)

The biggest problem with MVS is ambiguity: it exits 0 - false positive - whether there’s an obvious, reasonably-knowable, or non-obvious problem in the set of dependency versions its picked. Existing algorithms generally in the bundler/cargo/dep/pub/npm7 family (NP-hard search; preferring the latest version and avoiding known incompatibilities) clearly can do better at avoiding some such problems, at the cost of predictability. And, of course, they’re also still ambiguous - they’re not omniscient, and thus can’t avoid all false positives.

(Aside, a pet peeve: “predictability” != “determinism.” i am not aware of any nondeterministic version selection algorithms in production tooling.)

The price of this ambiguity is visible in more to the sort of issues Peter’s mentioned. It’s felt more in larger projects with deeper dependency graphs - e.g., k8s and anything depending on it. When things seem to work “well enough” with that exit 0 from MVS, you accept it and push ahead, because who’s gonna spend an hour spelunking a huge dep graph when everything at least seems fine? The result is what i called contagion failure in slow motion, manifesting like this. And once the seal’s broken, does doing it more really matter?

Ultimately, my view is that dealing with the information and ambiguity problems is the main path forward in this problem space. In that light, MVS is a local optimum, and the ideal version selection algorithms are on the NP-hard side, assuming we can also get predictability under control at the same time as ambiguity. (Clearly, i think that’s feasible.) Once we have those, the only sound basis for choosing MVS anymore will be as an easy-to-implement stepping stone. My guess is that Maven’s algorithm and encoding (the POM equivalent to require statements) will be preferable for that purpose.

I can only say that it works so well that I never needed to understand it deeper. My biggest chore related to dependencies is to clean go.sum files from time to time. I use go mod tidy for that.

I also run local go modules proxy (Athena) at home simply because I often update dependencies in multiple projects.

Here is a useful description of vgo from Cox with the details if you aren’t familiar with vgo and want to follow along with the discussion: https://research.swtch.com/vgo-principles

I used Go at work 2+ years ago, right when the new tooling was in beta, and it was such a relief then to ditch glide, dep, and the rest. For what it’s worth, the MVS algorithm seemed like it just codified the semantics that bundler, et al have in practice — in production applications, you move a single package at a time forward and let the minimum amount change.

I haven’t heard loud complaining in my circles, but I also exited Go development as I spent more time with sugary but still type-safe languages like Kotlin (mmm extension methods) and Typescript (mapped types give type-heavy Typescript an interesting feel), so I didn’t end up with a lot of first-hand experience with the new Go tooling.

Rust/Cargo uses maximum semver-compatible versions + lockfiles. It works ok. It’s not perfect, but it’s waaaay more reliable than npm — probably because of Rust’s strictness, built-in testing, and because the Rust compiler has much stronger backwards-compatibility than Node.js.

There’s an occasional “oops” when someone releases a patch update that should have been semver-major. It’s usually promptly resolved with a bugtracker complaint + yank. I’m a regular user of Rust, and I’d say I roughly waste an hour per year on the fallout of such things.

Cargo also supports an unstable -Z minimal-versions flag that resolves versions the way Go does. In theory it should work, as long as everyone has set minimum required versions precisely. However, the Cargo ecosystem is not compatible with MVS. Crate authors rely on Cargo picking latest versions, and don’t bother bumping version requirements themselves. There are many crates that require foo = "1.*", but then by accident use a feature added in 1.1. People do care about respecting semver for maximum version resolution.

Cargo/npm: I dread doing updates.

In cargo I have had breakage (requiring refactoring of my code) with updates to rust AND with updates to dependencies (direct or indirect).

In npm I have had breakage with updates to dependencies. Again requiring me to refactor code.

With Go: no breakage.

So. Many. Dependabot PRs.

I’ve followed its development and tooling issues from the start. I love MVS and the overall design. I think the biggest pain points have been tooling UX (which has come a long way and is getting quite nice) and SIV (semantic import versioning). In hindsight, I think SIV causes people a lot of UX issues. I think possibly there could have been an alternative convention for breaking changes since SIV is really just a convention that tooling supports and library authors have to understand and remember to use correctly anyway.

Surprisingly well. I wasn’t sure about it in the beginning, but stayed open-minded.

To be fair though, I think that things working great might be an after-effect of originally having no versioning. So initially there was a strong emphasis on creating good, stable APIs and less of a “let’s try and see” approach.

This means that various widely used libraries are more (API-)stable than in other ecosystems on average. Maybe that slowly changes, but since there’s that set of early, now established libraries I don’t think that effects would be seen too quickly.

Of course one might argue that the philosophy of things like the compatibility promise also have an effect and they certainly do, but I would not say this is a general theme, just like style guides, etc. laid out in official documentation isn’t followed by everyone, at least not beyond what the tooling tells you.

In other words, I would not assume that another language’s ecosystem would work that well, without all of that context. Of course not saying it wouldn’t work, just maybe things to keep in mind when making a decision based on Go doing this.