News for hackers. Stuff that matters.
Re:Go 1.17 is deprecating the traditional use of 'go get' by jen20 on Friday June 25, 2021 @04:59PM (#27636210)
...what?

GOPATH has nothing to do with GitHub. It is one of the places that has special case handling, but is absolutely not the purpose of GOPATH. Case in point: the VM I have to build some legacy stuff using GOPATH does not have a _single_ dependency from GitHub. Not one. Nor does it contain any open source code, besides the standard library.

Re:Go 1.17 is deprecating the traditional use of 'go get' by altfredd on Saturday June 26, 2021 @10:48AM (#27642326)
Indeed, — GOPATH does not imply using Github, and Github does not imply open-source (even if it is one of the most widely used ways to host open-source).

The logic of GOPATH and "go get" just so happen to revolve around building packages, fetched from source code repository. This logic used to be a stop-gap, written during early stages of Golang development, and makes it awkward (at best) to distribute proprietary Go libraries. I assume, that Google is introducing module system (and aggressively deprecating GOPATH) to work around this issue (among others).

Re:Go 1.17 is deprecating the traditional use of 'go get' by throwaway894345 on Friday June 25, 2021 @05:58PM (#27636772)
Yeah, the parent seems to think that GOPATH has something to do with pulling from GitHub and that modules implies some central repository which isn't the case at all. If you use modules, you're also pulling from GitHub directly in most cases, although nowadays there is a public caching proxy in the middle IIRC. And in both cases you could/can use private repositories.