The first problem I found using Go, was when I was figuring out how the module resolution worked along with the GOPATH, it became quite frustrating to set up a project structure with a functional local development environment.
Really?!
There is no magic. Create a directory anywhere and run go mod init. There is NO need for go virtual environments.
Personally, as someone who doesn't write Go but occasionally tries to compile Go projects, GOPATH/GOROOT caused me problems all of the last 3 or 4 times that I tried to compile a Go project, and I struggled to find clear explanations of what they should be set to. I felt like I was being stupid, and I'm sure I should have read the documentation better, but nevertheless, there's my data point.
Indeed that was a problem for many people and a key motivating factor to deploy the new go modules approach (which is enabled by default for a while now). Most of the projects out there now contain a go.mod file.
That said there may still be projects out there that are unmaintained or the author didn't bother to convert to go.mod, so you might occasionally still encounter GOPATH.
That's aggravating the problem. No only the original way was painful, but now there are multiple ways and to the newcomer that just needs to contribute to a project - it's all one big mess.
Agreed! I pick up Go a few times a year (which doesn't help, admittedly) and even consulting the official documentation, it's hard for me to figure out what the current, correct way of doing things is.
Dedicate 30m to read https://blog.golang.org/using-go-modules and try it out with a small demo project,e.g. write a small tool that emits a uuid; keep the toy project very small so you don't encounter other problems that might distract you from learning the basics of dependency management.
I can understand GOPATH, but why would GOROOT cause you any problems. I think you needed to set it way back in the go 1.3 days or something, but it's been a more or less hidden thing for a long time now.
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.
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 :)
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.
Really unfortunate the author missed this because the go tooling is really excellent and in 2020 you don’t need to know anything about GOPATH.
To be fair, this was this was absolutely an issue until very recent if you look at how long Go has been around, and there's still a ton of now outdated information out-there. I like Go, but that was one of the things I struggled with from the start years ago, and the GOPATH/GOROOT always felt like a dirty unnecessary hack.
Comments
Really?!
There is no magic. Create a directory anywhere and run go mod init. There is NO need for go virtual environments.
This is all well explained in the documentation. The first section of https://golang.org/doc/code.html
Really unfortunate the author missed this because the go tooling is really excellent and in 2020 you don’t need to know anything about GOPATH.
Personally, as someone who doesn't write Go but occasionally tries to compile Go projects, GOPATH/GOROOT caused me problems all of the last 3 or 4 times that I tried to compile a Go project, and I struggled to find clear explanations of what they should be set to. I felt like I was being stupid, and I'm sure I should have read the documentation better, but nevertheless, there's my data point.
Indeed that was a problem for many people and a key motivating factor to deploy the new go modules approach (which is enabled by default for a while now). Most of the projects out there now contain a go.mod file.
That said there may still be projects out there that are unmaintained or the author didn't bother to convert to go.mod, so you might occasionally still encounter GOPATH.
That's aggravating the problem. No only the original way was painful, but now there are multiple ways and to the newcomer that just needs to contribute to a project - it's all one big mess.
Agreed! I pick up Go a few times a year (which doesn't help, admittedly) and even consulting the official documentation, it's hard for me to figure out what the current, correct way of doing things is.
If you want to learn this my suggestion:
Dedicate 30m to read https://blog.golang.org/using-go-modules and try it out with a small demo project,e.g. write a small tool that emits a uuid; keep the toy project very small so you don't encounter other problems that might distract you from learning the basics of dependency management.
Search for dependencies using pkg.go.dev.
Either that or break backward compatibility. Pick your poison
I can understand GOPATH, but why would GOROOT cause you any problems. I think you needed to set it way back in the go 1.3 days or something, but it's been a more or less hidden thing for a long time now.
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.
I usually just "go-to-definition" to see where a dep is :)
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 :)
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.
To be fair, this was this was absolutely an issue until very recent if you look at how long Go has been around, and there's still a ton of now outdated information out-there. I like Go, but that was one of the things I struggled with from the start years ago, and the GOPATH/GOROOT always felt like a dirty unnecessary hack.
This advice only became valid a few months ago.
a few months here is at least 11 months, even more if you could the 1.12 release which was an rc for modules.