I've been programming in Go for a couple of years now and found that this need to use "hacks ... to avoid it" is totally naive and irrational.

Agreed, GOPATH is awkward--at first. Because it's different from what most programmers are used to. But once it's adopted it actually makes a lot of sense, and looking back it seems bizarre to ever have such a strong desire to avoid it at all costs--and the costs are high.

The same applies for Gofmt as well.

I should add that another big part of the reason I've been avoiding the language for years is the cult of Golang telling me my complaints are "totally naive and irrational".

I've been working with Go for 6 years, your complaints are not "totally naive and irrational".

I don't mind GOPATH, but I did argue that if vendoring was to be a thing then it needed to be dropped entirely. I was also not a fan of the vendoring mechanism.

The approach given here looks much more thought out getting rid of each, first proposal I've actually liked.

This kind of attitude around package management and especially dependency injection have been major turn-offs for me as well. More than a sufficient number of the community has been emitting a high-pressure stream of NIH combined with ignorance of existing solutions, and it has been crippling the community for years.

Dependency injection is very commonly used in the Go ecosystem. Do not confuse resistance about unidiomatic DI frameworks with resistance about DI itself.

Which ones are common? I've been hoping this would be the case, but I've been unable to find evidence for it.

e.g. the most-popular one I can see so far is Facebook's "inject", which has a remarkably small 841 stars: https://github.com/facebookgo/inject

Even Glide, Godep, and Dep have several thousand. And those can barely claim "most", much less "very common".

What do you mean which ones? I am talking about dependency injection as a technique/pattern. In Go you can just do it without importing anything.

Please read:

https://medium.com/@benbjohnson/standard-package-layout-7cdb...

(I've linked to the exact point in the article where it talks about DI but you might want to read the rest as well.)

Yeah, it's widespread as a hand-coded thing. It has to be - you essentially have no choice in Go for even basic things like tests.

But that just means that everyone rolls their own thing by hand, with widely-varying feature-sets, method names, bugs, etc. DI frameworks are very much nicer for interop between a bunch of libs.

gofmt, sure. Consistency in style is great.

But GOPATH was a mistake in the same way Go's hitherto lack of versioning was: it deliberately breaks easy isolation between projects / dependency management.

This mindset only works if you control most of the ecosystem (such as with a monorepo), but it's a irritating mess otherwise.

But you do control all the source code within your GOPATH! It's right there on your file system.

There's also a mechanism to take control of the same code even when it's outside your GOPATH. Github calls this mechanism a "pull request".

It's really not irrational to want to organize my projects in a way other than by their (current) git repo URL. It's also not irrational to not want disparate projects to not share the same pool of dependencies (which even go has begrudgingly accepted as evidenced by "dep" and this proposal). Go is alright but I refuse to drink the GOPATH cool aid.

It’s totally reasonable to want to organize projects in a different way, but I think GOPATH’s caveats are overstated.

- It’s an evironment variable, which makes it relatively easy to modify. To switch your dependencies from one pool to another, you can modify your GOPATH.

- The vendor directory lets you pin your dependencies per-project without modifying GOPATH. It’s not the most beautiful solution (and Go doesn’t often offer the most beautiful solution to any particular thing), but it’s workable.

GOPATH was weird to get used to at first, but I gave in and I actually store all my projects, even non-go projects, in the same folder hierarchy now. It has made me much more organized. In fact here's a zsh function I have for cloning new projects into that structure. It makes my home directory much less of a mess.

  gclone() {
  		dir=$(echo $1 | sed 's/^http\(s*\):\/\///g' | sed 's/^git@//g' | sed 's/\.git$//g' | sed 's/:/\//g' )
  		git clone $1  "$HOME/src/$dir"
  		cd "$HOME/src/$dir"
  }

Because you didn't want to set an env var?

The problem is not the env var, because whether or not it was set or with a default value, you have to clone the project https://github.com/foo/bar.git at ~/go/src/github.com/foo/bar and name the imports github.com/foo/bar accordingly and run the go commands from there. I used to (automatically) just export GOPATH="${PWD}/.gopath" but this doesn't work anymore since 1.8 or 1.9.

People† at large just want to clone https://github.com/foo/bar.git wherever they see fit, like directly at ~/Workspace/bar, ~/work/bar, ~/projects/contrib/bar or even /tmp/bar.

† "People" includes CI systems that expect the typical "clone and cd straight into" thing to work, resulting in a lot of boilerplate and/or symlink hacks to work around such expectations.

> Because you didn't want to set an env var?

You haven't needed to set a GOPATH since 1.8, which was released over a year ago (we're now at 1.10). Since 1.8, the Go toolchain will use a default GOPATH; the environment variable is only needed as an override.

GOPATH has a default. Unix: $HOME/go Windows: %USERPATH%/go

but on ci servers it could be akward.

For what reasons did you need to avoid it?

Some people want to store their projects in their own folder structure and not be forced to store it in the very weird way Go does it. I didn't avoid Go for this reason but I did find the whole Go workspace way it does things a big turnoff.

You say that because you have infinite filesystem space. I don't.

Though GOPATH avoids duplication, it's entirely possible to avoid duplication without GOPATH.

And downloading the full Git repository for every `go get` is frequently a far greater waste than even storing copies of all the versions you're currently using in all projects you work on.

GOPATH is unambiguously terrible.

you're right.