5 ms·

`go get` isn't a command you should be using to just be a handy way to clone a git repo to your PC. Yes, that was literally what it does today and that was effe

`go get` isn't a command you should be using to just be a handy way to clone a git repo to your PC. Yes, that was literally what it does today and that was effectively the workflow before modules. But GOPATH is deprecated so you shouldn't be relying on that anymore anyway. The expectation is that the user just clones your Git repo to _anywhere_ on their PC and runs `go test` there. If they want to consume this local development version in their application then they use a simple `replace` directive in their go.mod to point their dependency at their local version. If they're still using GOPATH then that's something they can probably manage themselves honestly. That's just a simple folder move. It's been like, what, nearly 2 years since GOPATH was deprecated?

jimmaswell 5y ago
This is everything wrong with modern languages/toolsets. Constantly changing everything, pulling the rug out from people who just want to get work done and wasting everyone's time who googles how to do something and has to go through 3 outdated answers to figure out the current way to do something. Deprecation and breaking changes should be an absolute last resort in the face of overwhelming necessity, not something done on a whimsy to please the aesthetic preferences of some new project manager who needs to feel important.
- 5e92cb50239222b 5y ago
  > This is everything wrong with modern languages/toolsets Go can hardly be called a modern language. The usual argument we hear on HN is that it has an absolutely stellar backwards compatibility story. Are we losing that too?
  - throwaway894345 5y ago
    > Go can hardly be called a modern language. I'm not sure what this means exactly, but it's a significant advance in simplicity and productivity in my experience. > The usual argument we hear on HN is that it has an absolutely stellar backwards compatibility story. This refers to the compatibility of the language, not necessarily the tooling. Even still, this is a single change, there's no need to panic about losing backwards compatibility just yet.
  - hda111 5y ago
    No language without FP or OOP can be called modern. Go is an ancient version of C with less features.
- loudlambda 5y ago
  Go is really bad at this. They claim to care strongly about backwards compatibility, but have repeatedly changed and broken how tooling works.
  - randomdata 5y ago
    It is Go, the language, that provides a backwards compatibility guarantee. Another tenant of Go, the language, is specification before implementation. There specifically so that many implementations of the language are created and do not become dependant on quirks of a single set of tools and enabling users to choose which tooling they prefer. Point being, there is a very clear line drawn between Go the language and the Go distribution. Guarantees provided by one are not necessarily applicable to another. Nor do they apply to gcc-go or tinygo.
- throwaway894345 5y ago
  I don't know that I disagree per se, but GOPATH and modules mean that the tooling has to handle two different cases which are often surprisingly ambiguous and it creates real headaches for the user. There's a lot to be said for having a single path forward even if it means existing users will have to experience some mild pain (i.e., learning a new workflow, rewriting some build scripts, etc) one time. Ideally language developers would have perfect foresight from the outset such that no changes are ever needed to the language, but sadly such language developers are hard to come by.
  - altfredd 5y ago
    > GOPATH and modules mean that the tooling has to handle two different cases... No, the main thing, that GOPATH meant, is that Google (and everyone else) had to make their Go libraries open-source — since entire logic of GOPATH revolves around building stuff, downloaded from Github. Once Google management decided to be serious about pushing Go to masses, they hurriedly rushed to erase GOPATH from history (just like they erased "Don't be evil" slogan from Internet after getting serious about doing business).
    - jen20 5y ago
      ...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.
      - throwaway894345 5y ago
        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.
      - 5y ago
harikb 5y ago
I knew it was optional. I didn’t know GOPATH was deprecated !
- Philip-J-Fry 5y ago
  To be clear, the whole GOPATH development workflow is deprecated. But the GOPATH environment variable isn't, since it's still used for configuring the location of other things like the module cache.
  - comeonseriously 5y ago
    Is there a convenient write up/tutorial of the latest suggested workflow that is "go get"-less and "GOPATH"-less?
blondin 5y ago
i use golang on and off and i always have to remind myself the difference between GOROOT, GOPATH, and GOSRC. the seeds of confusion was sowed from the get go.
- ghoward 5y ago
  > the seeds of confusion was sowed from the get go. I see what you did there...
icholy 5y ago
I wrote this little shim to replace the old `go get` behavior. https://github.com/icholy/git-get https://github.com/icholy/git-get

jimmaswell 5y ago

This is everything wrong with modern languages/toolsets. Constantly changing everything, pulling the rug out from people who just want to get work done and wasting everyone's time who googles how to do something and has to go through 3 outdated answers to figure out the current way to do something. Deprecation and breaking changes should be an absolute last resort in the face of overwhelming necessity, not something done on a whimsy to please the aesthetic preferences of some new project manager who needs to feel important.

5e92cb50239222b 5y ago
> This is everything wrong with modern languages/toolsets Go can hardly be called a modern language. The usual argument we hear on HN is that it has an absolutely stellar backwards compatibility story. Are we losing that too?
- throwaway894345 5y ago
  > Go can hardly be called a modern language. I'm not sure what this means exactly, but it's a significant advance in simplicity and productivity in my experience. > The usual argument we hear on HN is that it has an absolutely stellar backwards compatibility story. This refers to the compatibility of the language, not necessarily the tooling. Even still, this is a single change, there's no need to panic about losing backwards compatibility just yet.
- hda111 5y ago
  No language without FP or OOP can be called modern. Go is an ancient version of C with less features.
loudlambda 5y ago
Go is really bad at this. They claim to care strongly about backwards compatibility, but have repeatedly changed and broken how tooling works.
- randomdata 5y ago
  It is Go, the language, that provides a backwards compatibility guarantee. Another tenant of Go, the language, is specification before implementation. There specifically so that many implementations of the language are created and do not become dependant on quirks of a single set of tools and enabling users to choose which tooling they prefer. Point being, there is a very clear line drawn between Go the language and the Go distribution. Guarantees provided by one are not necessarily applicable to another. Nor do they apply to gcc-go or tinygo.
throwaway894345 5y ago
I don't know that I disagree per se, but GOPATH and modules mean that the tooling has to handle two different cases which are often surprisingly ambiguous and it creates real headaches for the user. There's a lot to be said for having a single path forward even if it means existing users will have to experience some mild pain (i.e., learning a new workflow, rewriting some build scripts, etc) one time. Ideally language developers would have perfect foresight from the outset such that no changes are ever needed to the language, but sadly such language developers are hard to come by.
- altfredd 5y ago
  > GOPATH and modules mean that the tooling has to handle two different cases... No, the main thing, that GOPATH meant, is that Google (and everyone else) had to make their Go libraries open-source — since entire logic of GOPATH revolves around building stuff, downloaded from Github. Once Google management decided to be serious about pushing Go to masses, they hurriedly rushed to erase GOPATH from history (just like they erased "Don't be evil" slogan from Internet after getting serious about doing business).
  - jen20 5y ago
    ...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.
    - throwaway894345 5y ago
      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.
    - 5y ago

harikb 5y ago

I knew it was optional. I didn’t know GOPATH was deprecated !

Philip-J-Fry 5y ago
To be clear, the whole GOPATH development workflow is deprecated. But the GOPATH environment variable isn't, since it's still used for configuring the location of other things like the module cache.
- comeonseriously 5y ago
  Is there a convenient write up/tutorial of the latest suggested workflow that is "go get"-less and "GOPATH"-less?

blondin 5y ago

i use golang on and off and i always have to remind myself the difference between GOROOT, GOPATH, and GOSRC. the seeds of confusion was sowed from the get go.

ghoward 5y ago
> the seeds of confusion was sowed from the get go. I see what you did there...

icholy 5y ago

I wrote this little shim to replace the old `go get` behavior. https://github.com/icholy/git-get https://github.com/icholy/git-get