Hacker News Reader

Comment by giancarlostoro | Hacker News Reader

After half a decade of not touching Go I went back to learning it. This was the one thing tripping me up. Not because I didnt understand it but because I cant even compile or pull in packages without defining some compiler variable flag witchcraft. I miss how simpler Go was. The compiler UX there really needs more TLC. Otherwise I still love what I loved about Go: a really incredible out of the box standard library which I highly attribute to Go's success since it allowed people to hit the ground running with Go much quicker.

View on HN

Was it ever easy? I remember hours trying to figure out what to set GOPATH and GOHOME to and how to get “go get” to actually work. I can’t help but think go is a wonderful language with a poor package manager unfortunately woven directly into the language. Really makes npm feel wonderful in comparison.

I found it quite easy to set two environment variables and never had issues with `go get` either.

"go get" is a disaster for any project of non trivial size. It was designed with the idea of a mono repo in mind - not a vast distributed network of independently evolving code repositories.

Never had any issues with that as soon as vendoring was an option. I routinely had/have three or more different non-trivial projects I was/am working on, and I dont recall ever having issues with go get. I started around maybe Go1.2. At first, I set GOPATH per project, but as soon as vendoring was a thing, one GOPATH to rule them all. Now, vendor updates to existing dependencies, there is something that has been a complete and utter disaster that hopefully gets better under the mod system.

I cannot for the life of me understand why they don't make setting up all those variables part of the installer (in the case of Windows, and possibly Mac?) / first time setup process, or define some sane defaults that don't get in your way. I can't help but feel most people likely have a similar enough setup to how I have my environment variables configured at the minimum, why not automate that repetitiveness at the installer / default configuration level.

There is a default for GOPATH these days, it's ~/go on unix.

wasn't the case on mac when i dled golang 2 months ago

Not sure what your experience was. Release 1.8 started the default GOPATH in Feb 2017, which is a tad over two months ago. Maybe you somehow got an older version.

Can you elaborate ? Which compiler flag is needed for compilation ?

Sorry it wasn't a compiler flag, it was an environment variable.

For Go modules if you don't have 'GO111MODULE' set to 'auto' or something appropriate, your code will whine about not being a module or something ridiculous. It will also cry about pulling in Go code with 'go get' if you don't have that environment variable properly configured.

The blog says that is only true if you put your code in GOPATH and the whole point of modules is that you don't need to do that.

Right, but anyone who is already using GOPATH for all their stuff now had to deal with this bizzare new flag. It was annoying for the few minutes it took me to realize what was going on and to fix it.

The default value of that environment variable is auto.

If you don't set anything, and you are inside GOPATH, module mode is disabled. If you are outside GOPATH, module mode is enabled.

I think that is the most sane behavior. And this flag is needed because modules are an experimental feature.

How else do you recommend to release experimental features ?

It wasn't auto in my case because I was getting errors till I defined it in Windows 10.

I mean that if it isn't set, the behavior is the same as auto. If you weren't getting "auto" behavior, then it's a bug. Please feel free to file an issue.

Reply on news.ycombinator.com