[losingthefight]

I mean, everyone is entitled to their own opinion, but I actually liked dep and never had a problem with it. With Go modules, it has been a massive problem converting our microservices over to Go modules, especially because some dependencies like Resty caused a lot of headaches and I lost several man weeks going through the process. Dep worked and modules doesn't seem to have brought us any real benefit, but again, my use case is my own and perhaps for you module was a better experience.

[atombender]

Go modules have some (minor, in my opinion) issues, but Dep was a total nightmare.

Dep was made by one of the authors of Glide, which coincidentally suffered from many of the exact same bugs, maybe because it reused some of the same code. Our entire team constantly had "dep ensure" failing in unpredictable ways (locally or on the CI server), usually caused by the solver not understanding something. These failures were completely incomprehensible and not fixable by the user. Dep's solver was also very slow.

From what I could tell, it was a combination of shoddy engineering and trying to do too much; if I remember correctly, Dep and Glide both tried to automatically detect and convert dependencies that used competing tools like Godep, which didn't work very well. For a long time, Dep didn't work at all with the Kubernetes client library, for example.

We've had almost zero problems with Go modules. I've encountered some minor bugs, but unlike Dep, nothing worth tearing my hair out.

The drama around Dep vs. Russ Cox shouldn't have happened, of course.

[no_wizard]

Any good documentation on using go modules day to day?

I have found the package management story around go so confusing its really stopped me from trying to use the language.

For context, I'm used to how composer/npm install the modules into a folder locally. I just can't seem to figure the go way of doing modules where I don't get completely confused.

[atombender]

The official wiki is good: https://github.com/golang/go/wiki/Modules

This article looks like a good intro: https://roberto.selbach.ca/intro-to-go-modules/

The equivalent of "npm install" is "go get" (optionally "-u"). You can also edit go.mod manually. Like NPM, this must be done within an application's root.

A point of confusion might be the difference between a module and a package. A package is just a folder that declares "package foo" at the top in all its Go files. A module is the closest analogue to an NPM package. Similar to NPM, a single Git repo can contain many nested modules. Unlike NPM, modules can be imported with Git -- no need to publish to a special registry.

When a Go file imports a package, the referenced package might live in a module outside your own. It knows it's outside your module because go.mod defines the full root path (e.g. github.com/foo/bar/baz) of your module.

You might experience some confusion when you look at how the new module system interacts with the old GOPATH way. Go current supports both modes.

[CamouflagedKiwi]

Indeed, I had exactly the reverse experience; dep never worked well, it was always moaning about obtuse errors ("project is not part of any GOPATH" etc) and was pretty slow even when it did, whereas go mod just worked almost flawlessly. I guess our mileages vary :)

[ploxiln]

Why did you go through it? You didn't have to, you could have waited a couple of years. dep still works. A custom script to populate a GOPATH with specific versions or forks of all needed modules still works.