Not just you. I've been using Go for many years, and while I enjoy the language I always found the environment of it awkward and unfriendly. Envvars on top of envvars. Work only in GOPATH, no wait, stop working in GOPATH. Vendor things...no wait don't do that either.
I think a lot of it is just growing pains, but it still feels clunky. My system has a .cache folder that everything already uses, why does Go need a special cache?
That seems... a bit much IMO. I personally prefer containerizing things. Such as Node.js’ way with node_modules. Then I can put my project wherever I want. Downloaded dependencies can also go in ~/.cache because I don’t plan on editing them.
Go projects using modules are permissive about where you put them (e.g. they don't have to be inside a GOPATH at the right location). It does still use a GOPATH for caching directories though, which seems normal enough. They have to go somewhere, usually declared in some env variable, or they have to have a default location and silently spread files all over. `go get` is not a binary installer, it's a go-project-downloader that happens to also be able to install binaries, so this is IMO expected as it doesn't toss the intermediate products (i.e. a temp folder is not a reasonable choice).
As for multi-language projects and conflicting layout needs: oh yeah, that's still terrible. Maybe try Bazel? It can break `go`(the CLI binary)'s rules and build any package from any source files, regardless of their locations. None of that is part of the language spec, `go` is just opinionated and inflexible (probably for simplicity).
and it's also just for depedencies it downloads.
_your_ code lives where you put it