5 ms·

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

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.

ithkuil 6y ago
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.
- dpc_pw 6y ago
  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.
  - nomofomo2 6y ago
    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.
    - ithkuil 6y ago
      If you want to learn this my suggestion: Dedicate 30m to read https://blog.golang.org/using-go-modules 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.
      - deleted 6y ago
        [deleted]
  - ithkuil 6y ago
    Either that or break backward compatibility. Pick your poison
saturn_vk 6y ago
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.

ithkuil 6y ago

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.

dpc_pw 6y ago
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.
- nomofomo2 6y ago
  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.
  - ithkuil 6y ago
    If you want to learn this my suggestion: Dedicate 30m to read https://blog.golang.org/using-go-modules 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.
    - deleted 6y ago
      [deleted]
- ithkuil 6y ago
  Either that or break backward compatibility. Pick your poison

saturn_vk 6y ago

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.