What problems do vendor/dependency managers solve in Go

I am very inexperienced in the golang world so it's safe to assume I know nothing.

What do tools like glide/godep provide that go get ... doesn't handle?

What is vendoring in the go ecosystem?

Is it similar to specifying a version in install.json for nodejs?

Tools like glide/godep/dep provide the equivalent of npm install + package.json of nodejs.

These tools allow you to specify which version of a dependency that your program use so that when you ship your code around or when someone wants to use your code, they can easily install the same version of the dependencies that you use. This is important to guarantee that it's reproducible, that it's 100% using the same thing and it's going to work the exact same way.

Vendoring is a fancy way of saying that you copy your dependencies in the vendor folder. Vendor is equivalent to node_modules.

What do tools like glide/godep provide that go get ... doesn't handle?

Let me illustrate with an example.

So let's assume you are working on awesome-go-project which uses unstable-dependency. So on your local computer you have:

go/src/github.com/xandout/awesome-go-project and
go/src/github.com/xataras/unstable-dependency

If you build a binary on your local machine and then deploy it on your server or always distribute binaries then all is good.

But let's suppose that a co-worker or just someone from the net wants to work on your awesome-go-project. So they use go get github.com/xandout/awesome-go-project to get it on their local machine. Meanwhile xataras has made a breaking change on unstable-dependency. So now the person that was interested in awesome-go-project will see that the code doesn't work.

So how do you ensure that awesome-go-project will always use a working version of unstable-dependency? You simply copy all the currently working unstable-dependency code in awesome-go-project and the convention/decision is for that to be copied under a vendor folder (so the various tools can automate the process).

go get doesn't allow you to specify which version of a library you want. It always pulls the latest.

Vendoring is making a copy of a package in your source tree underneath a vendor/ folder. The import path is still to the remote (github.com/org/example), but the code is actually within your repository.

It's similar to committing the node_modules folder in git.

git submodules solve all of this without any extra tooling - locked to a specific commit, whose code is not copied into the vendor directory unless needed, and even with the ability to fork the vendor and merge changes from upstream...

git submodules are a pain to use.

What problems do vendor/dependency managers solve in Go

Let's have some downvotes: None. Both pretend to solve a problem that provably has no automatic solution in the general case. So yes, they can be helpful. Like in having an add operation that sometime produces the correct result.

I went to get an old program to test it out and to my horror one of its deps didn't build. The dependency's maintainer has nuked the repository and moved it to a another url leaving only a deprecation notice in the old url.

I haven't encountered this in my projects, but I personally want to put my code up on GitHub one day and count on that it will build as it builds now for years.

Reproducibility.