Go for Java Developers - Part 2

This is my second post on things I’m finding interesting about the Go language. For additional background on this series you might want to read Part 1.

Dependency Management

This time I’m going to focus on dependency management and how go approaches the diamond dependency issue.

First off, Go does not support pre-compiled libraries the way Java does. (Personally, I think compiled Jar files are from a by-gone time and these days cause more harm than good, but that’s not why Go doesn’t have them.) Go doesn’t have them because Go code compiles down into native assembly so it would be impossible to distribute anything precompiled by Go and expect it to work on more than one platform.

So instead, Go publishes libraries as source code with Git tags and avoids artifactory all together. When you want to use a library you create a dependency on a git repo with a specific tag version.

This doesn’t exactly remove the diamond dependency issue as it is entirely possible to have a transitive dependency on two different versions of a library. In this case, as with Java, you still have to select the version you want to use. However, there are two substantial changes.

Can’t ignore the problem

First, you don’t have the option of ignoring or miss the issue. This means that if your service builds in Go, you can be confident your code does not contain any “hidden” mismatch errors. This effectively removes an entire class of errors that you have with Java. (TBH, these don’t pop up too often, but the more common a library is the greater the chance for this to happen. I’ve seen this error triggered with the Guava libraries.) Being able to completely remove them as a class of problems would be nice.

Conflicts identified at the source code level

Second, conflicts are identified at the source code level and not at the version level. This means that PATCH version mismatches won’t break your build so long as they don’t change function signature (and PATCHES really shouldn’t).

I’m not saying that the way Go deals with this is perfect but it does move the problem into a first class issue and forces a resolution. Java could take this same approach if you copied all of your dependencies into your code base as source code. But I did find it as an interesting consequence on how Go handles dependency management.