Each library needs to be build a JAR, which isn't the case in Go - in Go you just put in the code URL (git repo / branch / sha1) and you have it. Also locks the dependency to that sha1, and crypto verifies it. So you get all the benefits of building an artefact, hash verification and central repo without having to do any of the work.

> in Go you just put in the code URL (git repo / branch / sha1) and you have it

It seems you're thinking of the old Go dependency management.

The current Go dependency management, Modules, means that you put in the unique name of the Module (which is its URL) and the Semver-compatible version. Then go mod can resolve the exact code you need.

Sure, it's still source-code based, so you don't need to build a JAR file. Of course, that also means you can't have external dependencies that you pull in - you must have everything required to build your go module in that source code.

Go mod also checks version incompatibilities based on Semver and chooses the lowest specific version which matches everyone's Semver dependency specification.

Your source-control server must also know how to act as a go mod repository (it needs to respond to some go mod specific HTTP calls, as far as I could tell).

Now, when you want to publish a new version in Go, you don't build and publish a specific build to some extra repository. Instead, you need to tag some commit in your repo with a Semver version.

If you want to publish a new major version, you need to do much more than that, since any version higher than v1 will impact the name of your package in import statements in Go code (import "github.com/mymod/mypack" will become import "github.com/mymod/mypack/v2" in any code using your module, including internally).

Actually I find it a disadvantage, I don't want to deal with source code from other teams/companies, rather binary artifacts totally separated from their toolchains.

I find it a huge advantage, in fact the lack of blobs may be my favorite go feature. I'm sure stodgy old companies that want to preserve "IP" through security through obscurity, dislike this model.

But as a dev? I can drill down to the core (C-b in Goland, jump to definition) of ANY import. Even the entire go toolchain is in go.

ABI/version management of artifacts is a nightmare, every single time.

That is what debugging symbols are for.

Using binary dependencies doesn't preclude having access to source code if desired.

Same with Java unless they stripped symbols. Libs wouldn't be stripped though.

One of the reasons I use go is the production of static, self contained binaries. Wouldn't binary artifacts make that much more difficult?

Why should it? Static compiling has been a thing since compilers exist.

Dynamic linking only became mainstream in the mid-90s.

You can build self-contained Java JAR files for a while now.

To your points about integrity verification: maven does this too if you pass the `-C` flag.

One of the mayor benefits of maven/cargo repositories is that they are configured to be immutable. No issues with deleted repos or deleted/overwritten tags. Once your dependency is published it's there forever.

Why would I want to use your lib if you can't even trivially build it? haha.

That said, Gradle has git source dependency support as well.

One idea I like is to be able to depend on a branch. In Java it would be nice to depend on a branch, rather than dealing with snapshots.

Obviously that comes at the cost of coupling with the VCS. Maybe its not worth it. Interesting idea though.

The idea of a “branch” is not particularly novel, and I think any useful VCS will have an equivalence. I’d be perfectly fine with relying on that as much as I do any other aspect of a package manager.

Isn't that much harder to do with Go mod than with Maven?

With Maven, you can define your own versioning scheme and easily include the branch as a component of the version "number".

In Go mod, as far as I can tell, you have to have a Semver vMAJOR.MINOR.PATCH version, which is much more difficult to adjust for short-lived branches.