A lot of languages still haven't. A problem here is that this can't be solved by the package manager alone but needs support in the module loader too (often built into the language).

Python's PIP is getting a proper dependency solver, but there can still only be one package with a given name in an environment. So if package A needs numpy>=2 and package B needs numpy<2 there is no solution.

If you release a new major version of your package and you expect this will be a problem for people, you have to use a different package name (e.g. beautifulsoup4, jinja2). That is if the name for the next version isn't getting squatted on pypi.org.

That's a fair question and something I should have clarified in my comment (though I have a feeling it is likely addressed in the blog post I linked to).

It gets into the deeper motivation behind not breaking backwards compatibility within the same-named module. There are two bad extremes here:

1. Never update dependency versions for fear of breakage. This leaves you open to security vulnerabilities (that are easy to exploit because they are often thoroughly documented in the fixed version's changelog / code). And/or you're stuck with other bugs / missing features the upstream maintainer has already addressed.

2. Always just updating all deps to latest and hoping things don't break, maybe running the test suite and doing a "smoke test" build and run if you're lucky. Often a user becomes the first to find a broken corner case that you didn't think to check but they rely on.

The approach outlined by Rich Hickey in that Spec-ulation talk I linked to allows you to be (relatively) confident that a package with the same name will always be backwards-compatible and you can track the latest release and find a happy middle ground between those two extremes.

Go's approach is one of the few (only?) first-class implementations of this idea in a language's package system (in Clojure, perhaps ironically, this is merely a suggested convention). The Go modules system has its fair share of confusing idiosyncrasies, but this is one of my favorite features of it and I hope they stick to their guns.

It seems like this approach (including the major version number in the package name) has been practiced at the distro level for a long time. E.g. SDL 1.2 vs 2.0 have distinct package names on every distro I'm aware of.

It's short sighted to think that the Go package managment is "simple", there was a lot of thoughts and considerations that was put into it and improvements over other languages ( even recent one like Rust ).

Good read: https://research.swtch.com/vgo-principles which answers some of your questions.

"A lot of thought and consideration" was put into the ten previous approaches they've attempted to solve this problem.

I'm starting to think that the reason they've tried so hard to avoid solving interesting problems in the language is that every time they've tried they've made something worse than every other alternative that existed in the problem space.

With great effort, sometimes simple solutions are discovered.

Other languages don't allow you to import multiple versions of a package. Allowing this opens a can of worms, mostly to do with global state. The two versions of the module can still be competing for the same global resources, say lock files, or registering themselves somewhere, or just standard library stuff like the flag package. Unless developers actually test all their major versions running together, you are just crossing your fingers and hoping. It was the same problems we had with vendoring, and one of the reasons the 'libraries should not vendor' recommendation is made.

I'm not aware of maven allowing me to use multiple major-version libraries in the same package.

You can shade a dependency, which can with the requisite budget in frustration allow for importing a library with multiple versions in the same program.

http://maven.apache.org/plugins/maven-shade-plugin/

I think in conjunction with the minimum version selection it makes the dependency resolution much cheaper and simpler.

> Unlike in every single one of those other languages, this Golang decision means that you can't pin to a specific minor version

Yes, it is possible to pin to minor version.

The version is specified in the `go.mod` file.

Look at this [go.mod example](https://github.com/ukiahsmith/modbin1/blob/main/go.mod).

The upstream `modlib1` library at v4 has tagged versions for v4.0.0 and v4.1.0. The go.mod file pins the version to the _older_ v4.0.0.