[pandesal]

IMO I think that section in the docs is missing quite a bit of things when it comes to module resolution. I had the same issue when learning Go. It was quite confusing trying to figure out the node_modules(JavaScript) or _deps(Elixir) Go equivalent.

[saturn_vk]

I usually just "go-to-definition" to see where a dep is :)

[pandesal]

Sure, but that’s a terrible experience. Especially for a language marketing itself as simple. And just because you can “go-to-definition” to see where the dep is stored, it doesn’t answer questions like does every project dependency get stored there? What happens when another project somewhere locally has the same dep but a different version? Can you have deps locally stored in your project folder? All these can questions can be googled of course :)

[saturn_vk]

That kind of question need only be answered once though, in the documentation of the dependency system. In this case, all dependencies for go modules are stored in $GOPATH/pkg/mod/MODULE/PATH@version, but that's a minor detail that you don't really need to know, since the documentation also makes clear that all dependencies are downloaded in that directory, so you never have multiple copies of a single dependency with a single version. The documentation also specifies that you can download all your dependencies (or some), in a top-level (in respect to your module) vendor directory. All of these questions and more can be answered by `go help modules`.

Now, I use go-to-definition not because I want to find out where something is located, but what it looks like. The location is just exposed as a side-effect.