5 ms·

New Go release have broken a few workflows for me recently. I am spending more time answering 'Go questions' and not Pion questions. `go get github.com/pion/we

New Go release have broken a few workflows for me recently. I am spending more time answering 'Go questions' and not Pion questions. `go get github.com/pion/webrtc` used to pull into $GOPATH/src/github.com/pion/webrtc. That worked really well for new contributors. They get the code with one command and run `go test`. I wasn't able to just update the docs and recommend `go install` because it doesn't work with old Go versions. Is the expectation to put in the docs a sh snippet that does if/else on the Go version? I am grateful for modules though. Suprising the amount of people that still aren't using them (or aware at all!)

Philip-J-Fry 5y ago
`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
- 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
3np 5y ago
So it will be exactly one major version that supports both the new and old ways, as I read it? Sounds tight for such a significant change. I'd give it at least 2.I don't see the rush.
- icholy 5y ago
  The current version already supports both ways.
  - 3np 5y ago
    My bad!
kodablah 5y ago
> I wasn't able to just update the docs and recommend `go install` because it doesn't work with old Go versions I don't think your documentation has to be backwards compatible in this case. If you must split it into two sets of instructions based on Go versions, you can. But unlike many other ecosystems, in Go it's quite common to expect the developer to have moved to a somewhat recent version. I will say I had projects using dep and/or relying on a GOPATH-style directory layout with my build scripts, but that ship has sailed with just about any new libraries one might depend on. I don't think anyone would blame you for your library moving on too.
- rob74 5y ago
  I think people will be happy if the instructions work with the latest Go version (as opposed to instructions that are outdated either because the project is not maintained anymore or it is still maintained but nobody bothered to update the docs).
- yebyen 5y ago
  > in Go it's quite common to expect the developer to have moved to a somewhat recent version. People and organizations decide when they will move versions based on their own project lifecycles and requirements, usually (outside of the Go community?) not just because the language vendor says there is a new version and it's time. This is something that was hard for me to cope with as a Rubyist, who was always doing everything to be on the latest version. I'm new to the Go community, but I can already see the effects of this in Kubernetes, and I don't necessarily think it's good the way things are. Kubernetes 1.16 was released in 9/19 and already EOL and out of support in 8/20, less than a year later. (It took some time for many cloud vendors like AWS to catch up, EKS only landed K8s 1.16 in April 2020. That's four months of usable life before it was officially out of date.) Integrated things that worked in August of 2019, probably need work again in 2021. As a software developer I understand this and "yeah, we need to always be upgrading" is part of my mantra, and it has been clear to me since I was a teenager that I will spend time struggling with problems that I would not even know about, unless I run Debian "unstable" or an equivalent rolling release distro, where patches can be accepted from upstream at any time of year, whether or not they contain new features. But I could never get my bosses to see it this way, working in a company that was not firmly embanked inside of the "Cloud-Native" sphere of the world. The "normies" I've always worked with didn't want to see new features popping in at any time, they wanted their own predictable environment that works the same as it did yesterday, to stay that way all year long. (Edit: and for what it's worth, Ruby does a pretty good job of being stable all the time I've used it professionally for the last 8-10 years, and in spite of having chosen it themselves, they still hate it. Anyway, that's what they say they want...)
jmhodges 5y ago
I used to use `go get` for grabbing even non-Go repos but had to stop because of similar problems. I finally wrote a small tool to replace it I call `grab` https://github.com/jmhodges/grab https://github.com/jmhodges/grab to take over my "fetch the code and organize it into a tidy directory system" need It actually uses the nice VCS library guts that `go get` does!

Philip-J-Fry 5y ago

`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
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

3np 5y ago

So it will be exactly one major version that supports both the new and old ways, as I read it? Sounds tight for such a significant change. I'd give it at least 2.I don't see the rush.

icholy 5y ago
The current version already supports both ways.
- 3np 5y ago
  My bad!

kodablah 5y ago

> I wasn't able to just update the docs and recommend `go install` because it doesn't work with old Go versions I don't think your documentation has to be backwards compatible in this case. If you must split it into two sets of instructions based on Go versions, you can. But unlike many other ecosystems, in Go it's quite common to expect the developer to have moved to a somewhat recent version. I will say I had projects using dep and/or relying on a GOPATH-style directory layout with my build scripts, but that ship has sailed with just about any new libraries one might depend on. I don't think anyone would blame you for your library moving on too.

rob74 5y ago
I think people will be happy if the instructions work with the latest Go version (as opposed to instructions that are outdated either because the project is not maintained anymore or it is still maintained but nobody bothered to update the docs).
yebyen 5y ago
> in Go it's quite common to expect the developer to have moved to a somewhat recent version. People and organizations decide when they will move versions based on their own project lifecycles and requirements, usually (outside of the Go community?) not just because the language vendor says there is a new version and it's time. This is something that was hard for me to cope with as a Rubyist, who was always doing everything to be on the latest version. I'm new to the Go community, but I can already see the effects of this in Kubernetes, and I don't necessarily think it's good the way things are. Kubernetes 1.16 was released in 9/19 and already EOL and out of support in 8/20, less than a year later. (It took some time for many cloud vendors like AWS to catch up, EKS only landed K8s 1.16 in April 2020. That's four months of usable life before it was officially out of date.) Integrated things that worked in August of 2019, probably need work again in 2021. As a software developer I understand this and "yeah, we need to always be upgrading" is part of my mantra, and it has been clear to me since I was a teenager that I will spend time struggling with problems that I would not even know about, unless I run Debian "unstable" or an equivalent rolling release distro, where patches can be accepted from upstream at any time of year, whether or not they contain new features. But I could never get my bosses to see it this way, working in a company that was not firmly embanked inside of the "Cloud-Native" sphere of the world. The "normies" I've always worked with didn't want to see new features popping in at any time, they wanted their own predictable environment that works the same as it did yesterday, to stay that way all year long. (Edit: and for what it's worth, Ruby does a pretty good job of being stable all the time I've used it professionally for the last 8-10 years, and in spite of having chosen it themselves, they still hate it. Anyway, that's what they say they want...)

jmhodges 5y ago

I used to use `go get` for grabbing even non-Go repos but had to stop because of similar problems. I finally wrote a small tool to replace it I call `grab` https://github.com/jmhodges/grab https://github.com/jmhodges/grab to take over my "fetch the code and organize it into a tidy directory system" need It actually uses the nice VCS library guts that `go get` does!