16 ms·

Go 1.17 is deprecating the traditional use of 'go get'

265 points by nitinreddy88 5y ago

Macha 5y ago
So is Go an unstable ecosystem not yet suitable for production use? (The answer of course, is no, but other languages get skewered for less).
- deleted 5y ago
  [deleted]
rightbyte 5y ago
I am happy I changed job from DevOps so I don't have to deal with stuff like this breaking all the time for no good reason at all (on more computers than mine). Backwards compatibility is gold.
- laumars 5y ago
  ‘go get’ is older than ‘pip’. The way Go packages are versioned and referenced has evolved massively since then. I get the need for backwards compatibility, I really do, but if you can’t modernise 11 year old tech then I think you’re on the road to much bigger problems. Edit: correction, Pip is older than Go. But for those downvoting me, the dates were just an illustration and don’t really matter to the point I’m making. That point being: after 11 years it should be safe to update a legacy interface.
  - jcelerier 5y ago
    pip is older than go lol
    - laumars 5y ago
      Nope > Initial release: 4 April 2011 (10 years ago) Source: Wikipedia, pip (package manager).
      - forgetfulness 5y ago
        It was a rebranding of the 2008 pyinstall as the same Wikipedia article states in the first section. Like other things in Go, the antiquated feel is actually the pursuit of retro more than the product of age.
        laumars 5y ago
        > It was a rebranding of the 2008 pyinstall as the same Wikipedia article states in the first section. Fair point. I’m on my phone so missed that section when scrolling through for the summary box. > Like other things in Go, the antiquated feel is actually the pursuit of retro more than the product of age. I’m really not sure the point you’re trying to make here but it feels like a baseless cheap shot rather than a constructive comment
      - jcelerier 5y ago
        wikipedia is wrong https://pypi.org/project/pip/0.2/ https://pypi.org/project/pip/0.2/ Released: Oct 28, 2008
    - deleted 5y ago
      [deleted]
  - abryzak 5y ago
    According to [1], version 0.2 of pip was released 2008-10-29. The 1.0 release which added Python 3 support was 2011-04-04 (which is what Wikipedia lists). The earliest release I can find for Go at [2] is 2009-12-09, with 1.0 being released 2012-03-28. [1] https://pypi.org/project/pip/#history https://pypi.org/project/pip/#history [2] https://golang.org/doc/devel/weekly https://golang.org/doc/devel/weekly
  - mfer 5y ago
    The new behavior could easily have been `go mod get`. There are many ways to design things to not break people. When it comes to the tools, the Go team isn't concerned with breaking people. Their docs even note that.
    - laumars 5y ago
      You’re missing the point because ‘go mod get’ would cause the same deprecation notice. The complaint isn’t what the new command looks like, it’s that the old one is being deprecated.
  - cryvate1284 5y ago
    What's the relevance of it being older than `pip`?
    - laumars 5y ago
      It’s just an illustration to help conceptualise the point. Like when people talk about larger distances using comparisons like “lengths of a football field”. The purpose was just demonstrating that the tooling in question is as old as many of the other common tooling used in other languages, rather than some recent thing that’s prone to frequent changes.
      - laumars 5y ago
        Why is this being downvoted? It was literally just answering the asked question!
- slver 5y ago
  Platforms that are not willing to deprecate parts of themselves in order to spur innovation and keep complexity low, eventually get deprecated as a whole. Look at Java, the king of BC, even they've started deprecating packages in the JDK for removal. It's inevitable. Otherwise it's like a brain that can't forget even the most useless piece of information. About an organism that just eats, but can't expel the waste. There's a way to do change slowly, gradually and reasonably, but change is inevitable. If you don't want small changes, big changes will come for you.
  - superkuh 5y ago
    No one is arguing for no change. The problems here are the new single corporation languages from this past decade that behave like 6 months is a long time. It isn't. Every ~4 years is more the cadence of everything before.
    - jodrellblank 5y ago
      HN person a few days ago: "It's pretty common that I have to deal with support issues that were fixed six months ago, but the client has never taken an update in all that time..." - https://news.ycombinator.com/item?id=27492147 https://news.ycombinator.com/item?id=27492147 I was surprised to see six months described as "never, in all that time".
  - rightbyte 5y ago
    Ye I understand that, but from a DevOp or system admin perspective all these small things adds up. 6 months deprecation is way too short to first realize this is changing and then fix all the scripts - and most likely still keeping backwards compability with older Go versions in the scripts for projects stuck in older versions. The remedy in practice is pinning versions by project or even worse org. wide to be able to concentrate on the actual problem being solved if things are breaking too much.
    - icholy 5y ago
      No one is forcing you to update.
Sean-Der 5y ago
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?
bla3 5y ago
Go spends a lot of effort on making sure the language is backwards compatible. Which is great! Weird they're so nonchalant about tooling changes.
- janslow 5y ago
  In most cases, a breaking tooling change should only impact the root project (e.g., they need to change their readme from `go get` to `go install`), so there's only one codebase to fix and it's in the control of the person upgrading the tooling. Whereas, a breaking language change could impact transitive dependencies of the root project, which a developer doesn't have control over.
  - throwaway894345 5y ago
    Moreover, breaking a language change can result in many changes over any given project including insidious bugs. Breaking the tooling behavior means you have to update your build script and your workflow. Meh.
mseepgood 5y ago
I thought this was already deprecated? I remember updating my docs a couple of months ago when Go 1.16 came out.
haolez 5y ago
I never understood the need for modules and versioning in the first place. You can do censoring by forking your dependency's repo and keeping it the way you want it.
- kortex 5y ago
  Do you mean vendoring, not censoring? Either way, this is a terrible way to do it. I've lived it. It results in libraries that don't work unless you freeze to exact git hashes of dependencies and never evolve because it's too painful.
smasher164 5y ago
If the author or anyone feels really strongly about `go get`'s deprecation, the issue for it is http://golang.org/issue/43684 http://golang.org/issue/43684.
klodolph 5y ago
> There are quite a lot of open source programs written in Go out there that currently say to install them with 'go get ...' in their READMEs and other resources. My experience is that a fair number of these utilities are broken anyway, because they rely on "go get" to fetch dependencies, and the dependencies they use have changed too much. (Yes, that shouldn't happen, but it does happen, and it's one of the major problems that go.mod fixes. You can shame library authors for making backwards-incompatible changes, but that won't fix your tools.)
- Cthulhu_ 5y ago
  I'm going to be harsh; if those dependencies don't update themselves, they have been abandoned and should be migrated away from.
  - progval 5y ago
    They could be getting non-breaking updates, though.
tut-urut-utut 5y ago
I never liked "go get" approach to dependency management in Go. It always seemed wrong. Even npm or maven got it better. On the other hand, deprecating a critical tool of infrastructure leaves a sour taste. Many people would be pissed of. Better not including it in the first place. IMHO such tooling should not be part of the language itself, and be left to the community.
- mikepurvis 5y ago
  Speaking from the perspective of someone with a fair bit of exposure to packaging and shipping software in the Python world, I don't thinking leaving these matters to "the community" results in a satisfactory outcome. In more practical terms, I expect this tooling is provided and evolved as a first class affair because Google needs it internally to build their golang projects.
  - throwaway894345 5y ago
    See also C and C++.
- cortesoft 5y ago
  I disagree on the idea of leaving tooling up to the community. Having one set of tooling that everyone uses is a huge advantage. It really helps projects interoperate with other projects.
- marvinblum 5y ago
  > IMHO such tooling should not be part of the language itself, and be left to the community. I strongly disagree with this. "All batteries included" is one of Go's strongest points, especially if you look at gofmt, which set a standard for all code out there.
  - samcal 5y ago
    Yeah, I heard this a lot about go. Agree that gofmt is a good call, but it’s not hard to get that one right. I’m seeing more and more of these “included batteries” being deprecated, it’s almost as if standard libraries don’t stay shiny and new forever ;)
sethammons 5y ago
I prefer this change. ‘go get $PKG’ will now only bring in source code. To install the related binary if $PKG is a tool, use ‘go install $PKG’. Honestly, that is honestly how I already operated and I didn’t like that you might auto-install a tool when all you wanted was its source. Never remembered the flags.
Cthulhu_ 5y ago
Are they just deprecating it, or removing it? Removing it goes against the backwards compatibility thing they're proud of. I have no objections if they choose to remove it for go 2.
jchw 5y ago
Agreed regarding deprecation schedule. It’s hard to break old habits. However I do totally understand why, as a person who has more than once become ridiculously confused because I accidentally ran go get in a directory that was a Go module. Somehow I even managed to make my home directory a Go module, leading to a lot more confusion. Needless to say, they do need to fix that somehow. They probably should’ve gone the other direction and made a new go get command that was specific to modules. It’s a bit too late to do that now. Go modules overall have been reasonably smooth but I’m a bit disappointed since this particular break will cause a lot of confusion. I think most likely in the long term it will pay off, but it’s probably unnecessarily abrupt. Maybe this is being done to lead into Go 2? Honestly, I do have another wish: I wish there was a version of “go run” that could fetch, compile and run directly from the Internet. Now I realize that’s not particularly safe, but it’s not much unsafer than doing it in two steps, and man would it be slick for small demos.
floren 5y ago
I'm in favor of firming up the roles of `go get` and `go install`--it was damn weird that running `go get github.com/foo/bar` did one thing inside a Go project and another outside it. Growing pains of the introduction of Go modules and the deprecation of GOPATH and what-not. My bigger complaint, though, is that the Go team have decided to ignore replace directives when you call `go install`. In a perfect world, I find a bug in an upstream library, submit a fix, and they accept it. In practice, lots of upstream maintainers check their issue/PR lists about once a month if you're lucky, so the best way to temporarily fix the problem is to put in a replace directive changing github.com/foo/bar -> github.com/me/bar until the PR goes in. Except `go install` will ignore that, so if you install a tool via `go install` you get the broken library, but if you git clone the repo and run `go build`, you get the fix. In proper Go team fashion, they have declared that because sometimes replace directives are difficult, they refuse to deal with them at all--if you intend to distribute something for use with go install, you better fork the dependency and update all your source files.
- pa7ch 5y ago
  'go install pkg@version' will error on replace directives rather then ignore. I fought hard in the github issues to make go install error on replace as a compromise to ignoreing it which creates two subtly different build modes! Also by erroring we leave open the possibility to eventually change it to build correctly with the replace directives without breakage. Add your voice that @version cmds should respect all replace directives that they reasonably can!
  - floren 5y ago
    Thank you for the correction, and thank you for fighting for it! I agree that errors are far better than silently ignoring it. I'll weigh in on the issue tracker if I remember later.
- sudhirj 5y ago
  In the interest of fairness, shouldn't this finish with: > In proper Go team fashion, they have declared that because sometimes replace directives are difficult,... they've asked for proposals that can be publicly vetted and discussed? The line has been "submit a proposal, let's review it" as long as I can remember.
xorvoid 5y ago
Idk.. the alternative seems like a Python 3 nightmare. People start depending on things and then you’re faced with two choices: (1) break lots of people, (2) hold on to every bit of ugly broken legacy stuff in the name of backwards compat. At this point, I feel like the entire solution space has been explored between all the different languages and there is not a great solution from any of them. Personally, I’m much happier with Go breaking things than becoming a C/C++ hole of legacy going back like 50+ years. On the timing and speed (only one version warning before removal): we can debate the right speed until the cows come home. But, Python 3 took longer than a decade to kill Python 2 as they were trying to give people “plenty of time”. In the end (IMHO), people don’t change unless they’re aggressively forced to because there is always something better to do with your time than upgrade software to prevent some possible future hypothetical breakage. That calculus changes when it’s not hypothetical at all.
- ryandvm 5y ago
  Agreed. Python 3 and IPv6 are case studies in how not to do an upgrade. While I can appreciate the care and engineering skill involved in upgrading a technology while still having backward compatibility, it turns out just to enable the worst possible behavior on the consumer end. I think I like Apple's way of just forcing breaking changes down everyone's throats (e.g. removing CD/DVD, PowerPC->x86, 30-pin->Lightning, dropping headphone port, etc.). Sure the tech media complain for a cycle, but then everybody adapts and the world's a better place.
  - XorNot 5y ago
    There was literally no choice when it came to IPv6. Everyone who thinks they've got a clever compromise is forgetting that it's not a software problem where it matters.
    - drran 5y ago
      Embrace Extend Extinguish I vote for IPv5 protocol, which will allow to cal any IPv4 host via IPv5-IPv4 NAT transparently at nearest bridge. WHY I cannot do `ping6 127.0.0.1`? WTF? Is IPv6 is too small for whole IPv4 address space?
chucke 5y ago
> Yes, this approach is in some sense more correct; it's also less humane. It's robot logic (also).) Sums up the go philosophy to me. A machine-first language, forces developers to think like a computer.
- morelisp 5y ago
  We've had substantially more success at this than teaching computers to think like developers, so, sounds fine.
John23832 5y ago
The use of `go get` vs `go install` was always confusing to me. Especially with the release of modules. I say this is a change for the better. The cli is more consistent. The argument made in the post seems more like a philosophical "wah, wah, I don't want to".
- pa7ch 5y ago
  Agreed. They originally almost made this new cmd a special flag on go get leaving go get and install alone. Now they finally clearly do one thing each. Might be painful but its clean break for the better now.
thomasfedb 5y ago
There's value in delightfulness in CLI tools. Having "go get" be the incantation for Go to go and get something, that's a nice experience for a dev, particuarly when you're picking up the language/tooling.
dwheeler 5y ago
I agree with the author, that is a ridiculously short time for a breaking change in widely-used functionality. Every "update that breaks things" is teaching your users to not update the software, ever. Frankly, it's hurtful to users. By all means send the deprecation warning, but give a lot more time before removing the functionality. Tools require time to get widely distributed unless there's a huge emergency. In this case, there's no need for the hurry.
tonfreed 5y ago
Cool, but where are my generics?
gunapologist99 5y ago
This is not a deprecation of the language, or even a small part of the language, and it's certainly a lot less than dumping huge parts of an existing and functional language as we saw with python 3 and perl 6. This is simply changing the command-line options that you would do on a somewhat occasional basis, but it does not require changes to any code (except for, perhaps, installation shell scripts or install docs.) This does not infringe on the Go backwards-compatibility promise that attracted me to Go in the first place in any way, and it helps clarify a confusing situation. It's a win-win.
moondev 5y ago
I'm most excited about "go run" supporting import paths in 1.17, similar to how npx works for node
airhead969 5y ago
Lessons (not) learned: Go never worked well with semantic versioning or packaging, didn't mature and evolve as a language fast enough for productivity at scale in ways users wanted, became stuck in its ruts, and was overwhelmed by an influx of trend-following noobs. I bounced because its stiltedness never seemed to improve.
Thaxll 5y ago
tbh it's not really a breaking change, it's for getting binary, it has nothing to do with compiling Go code or the Go language itself. I don't remember the last time I had to to use go get to download a binary ( I'm using wget or curl for that ).
fnord123 5y ago
>The bigger thing is that this particular deprecation is probably going to mean that fewer people use utilities and other programs written in Go. There are quite a lot of open source programs written in Go out there that currently say to install them with 'go get ...' I can tell you that in the wild, non go programmers do not use tools installed using the go compiler that they do not have installed. It's apt, brew, $WINDOWS_PACKAGE_MANAGER, flatpak, etc. I imagine precious few people install docker or sysdig using `go get`.
omginternets 5y ago
I'm not sure what the issue is: 1. `go get` will work as expected when run from a directory with a go.mod (or have I misunderstood?) 2. Given the above, the argument about people who include `go get` in their GitHub READMEs makes little sense. Those who blindly copy `go get` from a README will quickly learn to run `go mod init` to set up their projects. 3. There is a deprecation warning, giving everyone plenty of time to adjust to these minimal changes. Where's the big deal? I'm reminded of this popular XKCD comic: https://xkcd.com/1172/ https://xkcd.com/1172/
geofft 5y ago
> The bigger thing is that this particular deprecation is probably going to mean that fewer people use utilities and other programs written in Go. I kept hearing this about Python 2->3, specifically in the context that people would start writing stuff in Go instead. And it was a little bit true, sure, but there's plenty of stuff that's still in Python that people still figure out how to use. So I'm deeply amused to hear that people are going to switch away from utilities written in Go and curious what language they're switching to.
skybrian 5y ago
If the error message is something decent like “please run ‘go install’ instead” then it seems like users are going to learn the new command rather than giving up? It might be more a problem if ‘go get’ is used to install commands in installer scripts.
hda111 5y ago
I don’t get why people use Go. It’s just an awful language without OOP and without FP. Looks like an ancient language compared to Rust.
dcow 5y ago
I might agree with the author if `go get` wasn't such a terrible and confusing command in the first place. It actively deceives users new to go now that modules are a thing because it does not do what you would expect if you are in a directory with a .mod file. Projects that list “go get” as the install method do not work in subtle and surprising ways for users new to the language, period. It’s 2021 go modules have been around for what 6 minor versions now? Flows have been convoluted (broken) for quite some time. The author fails to discuss the real issue and is simply pandering to some “but workflows might break” argument. If you have a workflow that depends on go get and you aren't using modules you will have at least months to update it to go install.
flyinprogrammer 5y ago
Plug for: https://github.com/goreleaser/goreleaser https://github.com/goreleaser/goreleaser https://github.com/goreleaser/godownloader https://github.com/goreleaser/godownloader
deleted 5y ago
[deleted]
phendrenad2 5y ago
How do we solve the problem of clueless maintainers breaking everyone's shit? How do we make them understand that their urge to homogenize and rectify and beautify all APIs is causing people anguish. Do they just not care?
jd3 5y ago
for everyone else that was confused about why an article titled > Go 1.17 is deprecating the traditional use of 'go get' did not link to the original proposal/implementation issues: initial proposal: https://github.com/golang/go/issues/40276 https://github.com/golang/go/issues/40276 1.16 deprecation delay: https://github.com/golang/go/issues/42885 https://github.com/golang/go/issues/42885 1.17 deprecation: https://github.com/golang/go/issues/43684 https://github.com/golang/go/issues/43684
anthk 5y ago
Why doesn't go build extra dependencies in the current directory instead of polluting $GOPATH/src ?
thiht 5y ago
> Go will be printing a warning for only one release, which means six months or so. Seems more than fair to me. Nothing to see here.

265 points by nitinreddy88 5y ago

So is Go an unstable ecosystem not yet suitable for production use? (The answer of course, is no, but other languages get skewered for less).

deleted 5y ago
[deleted]

rightbyte 5y ago

I am happy I changed job from DevOps so I don't have to deal with stuff like this breaking all the time for no good reason at all (on more computers than mine). Backwards compatibility is gold.

laumars 5y ago
‘go get’ is older than ‘pip’. The way Go packages are versioned and referenced has evolved massively since then. I get the need for backwards compatibility, I really do, but if you can’t modernise 11 year old tech then I think you’re on the road to much bigger problems. Edit: correction, Pip is older than Go. But for those downvoting me, the dates were just an illustration and don’t really matter to the point I’m making. That point being: after 11 years it should be safe to update a legacy interface.
- jcelerier 5y ago
  pip is older than go lol
  - laumars 5y ago
    Nope > Initial release: 4 April 2011 (10 years ago) Source: Wikipedia, pip (package manager).
    - forgetfulness 5y ago
      It was a rebranding of the 2008 pyinstall as the same Wikipedia article states in the first section. Like other things in Go, the antiquated feel is actually the pursuit of retro more than the product of age.
      - laumars 5y ago
        > It was a rebranding of the 2008 pyinstall as the same Wikipedia article states in the first section. Fair point. I’m on my phone so missed that section when scrolling through for the summary box. > Like other things in Go, the antiquated feel is actually the pursuit of retro more than the product of age. I’m really not sure the point you’re trying to make here but it feels like a baseless cheap shot rather than a constructive comment
    - jcelerier 5y ago
      wikipedia is wrong https://pypi.org/project/pip/0.2/ https://pypi.org/project/pip/0.2/ Released: Oct 28, 2008
  - deleted 5y ago
    [deleted]
- abryzak 5y ago
  According to [1], version 0.2 of pip was released 2008-10-29. The 1.0 release which added Python 3 support was 2011-04-04 (which is what Wikipedia lists). The earliest release I can find for Go at [2] is 2009-12-09, with 1.0 being released 2012-03-28. [1] https://pypi.org/project/pip/#history https://pypi.org/project/pip/#history [2] https://golang.org/doc/devel/weekly https://golang.org/doc/devel/weekly
- mfer 5y ago
  The new behavior could easily have been `go mod get`. There are many ways to design things to not break people. When it comes to the tools, the Go team isn't concerned with breaking people. Their docs even note that.
  - laumars 5y ago
    You’re missing the point because ‘go mod get’ would cause the same deprecation notice. The complaint isn’t what the new command looks like, it’s that the old one is being deprecated.
- cryvate1284 5y ago
  What's the relevance of it being older than `pip`?
  - laumars 5y ago
    It’s just an illustration to help conceptualise the point. Like when people talk about larger distances using comparisons like “lengths of a football field”. The purpose was just demonstrating that the tooling in question is as old as many of the other common tooling used in other languages, rather than some recent thing that’s prone to frequent changes.
    - laumars 5y ago
      Why is this being downvoted? It was literally just answering the asked question!
slver 5y ago
Platforms that are not willing to deprecate parts of themselves in order to spur innovation and keep complexity low, eventually get deprecated as a whole. Look at Java, the king of BC, even they've started deprecating packages in the JDK for removal. It's inevitable. Otherwise it's like a brain that can't forget even the most useless piece of information. About an organism that just eats, but can't expel the waste. There's a way to do change slowly, gradually and reasonably, but change is inevitable. If you don't want small changes, big changes will come for you.
- superkuh 5y ago
  No one is arguing for no change. The problems here are the new single corporation languages from this past decade that behave like 6 months is a long time. It isn't. Every ~4 years is more the cadence of everything before.
  - jodrellblank 5y ago
    HN person a few days ago: "It's pretty common that I have to deal with support issues that were fixed six months ago, but the client has never taken an update in all that time..." - https://news.ycombinator.com/item?id=27492147 https://news.ycombinator.com/item?id=27492147 I was surprised to see six months described as "never, in all that time".
- rightbyte 5y ago
  Ye I understand that, but from a DevOp or system admin perspective all these small things adds up. 6 months deprecation is way too short to first realize this is changing and then fix all the scripts - and most likely still keeping backwards compability with older Go versions in the scripts for projects stuck in older versions. The remedy in practice is pinning versions by project or even worse org. wide to be able to concentrate on the actual problem being solved if things are breaking too much.
  - icholy 5y ago
    No one is forcing you to update.

Sean-Der 5y ago

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?

bla3 5y ago

Go spends a lot of effort on making sure the language is backwards compatible. Which is great! Weird they're so nonchalant about tooling changes.

janslow 5y ago
In most cases, a breaking tooling change should only impact the root project (e.g., they need to change their readme from `go get` to `go install`), so there's only one codebase to fix and it's in the control of the person upgrading the tooling. Whereas, a breaking language change could impact transitive dependencies of the root project, which a developer doesn't have control over.
- throwaway894345 5y ago
  Moreover, breaking a language change can result in many changes over any given project including insidious bugs. Breaking the tooling behavior means you have to update your build script and your workflow. Meh.

mseepgood 5y ago

I thought this was already deprecated? I remember updating my docs a couple of months ago when Go 1.16 came out.

haolez 5y ago

I never understood the need for modules and versioning in the first place. You can do censoring by forking your dependency's repo and keeping it the way you want it.

kortex 5y ago
Do you mean vendoring, not censoring? Either way, this is a terrible way to do it. I've lived it. It results in libraries that don't work unless you freeze to exact git hashes of dependencies and never evolve because it's too painful.

smasher164 5y ago

If the author or anyone feels really strongly about `go get`'s deprecation, the issue for it is http://golang.org/issue/43684 http://golang.org/issue/43684.

klodolph 5y ago

> There are quite a lot of open source programs written in Go out there that currently say to install them with 'go get ...' in their READMEs and other resources. My experience is that a fair number of these utilities are broken anyway, because they rely on "go get" to fetch dependencies, and the dependencies they use have changed too much. (Yes, that shouldn't happen, but it does happen, and it's one of the major problems that go.mod fixes. You can shame library authors for making backwards-incompatible changes, but that won't fix your tools.)

Cthulhu_ 5y ago
I'm going to be harsh; if those dependencies don't update themselves, they have been abandoned and should be migrated away from.
- progval 5y ago
  They could be getting non-breaking updates, though.

tut-urut-utut 5y ago

I never liked "go get" approach to dependency management in Go. It always seemed wrong. Even npm or maven got it better. On the other hand, deprecating a critical tool of infrastructure leaves a sour taste. Many people would be pissed of. Better not including it in the first place. IMHO such tooling should not be part of the language itself, and be left to the community.

mikepurvis 5y ago
Speaking from the perspective of someone with a fair bit of exposure to packaging and shipping software in the Python world, I don't thinking leaving these matters to "the community" results in a satisfactory outcome. In more practical terms, I expect this tooling is provided and evolved as a first class affair because Google needs it internally to build their golang projects.
- throwaway894345 5y ago
  See also C and C++.
cortesoft 5y ago
I disagree on the idea of leaving tooling up to the community. Having one set of tooling that everyone uses is a huge advantage. It really helps projects interoperate with other projects.
marvinblum 5y ago
> IMHO such tooling should not be part of the language itself, and be left to the community. I strongly disagree with this. "All batteries included" is one of Go's strongest points, especially if you look at gofmt, which set a standard for all code out there.
- samcal 5y ago
  Yeah, I heard this a lot about go. Agree that gofmt is a good call, but it’s not hard to get that one right. I’m seeing more and more of these “included batteries” being deprecated, it’s almost as if standard libraries don’t stay shiny and new forever ;)

sethammons 5y ago

I prefer this change. ‘go get $PKG’ will now only bring in source code. To install the related binary if $PKG is a tool, use ‘go install $PKG’. Honestly, that is honestly how I already operated and I didn’t like that you might auto-install a tool when all you wanted was its source. Never remembered the flags.

Cthulhu_ 5y ago

Are they just deprecating it, or removing it? Removing it goes against the backwards compatibility thing they're proud of. I have no objections if they choose to remove it for go 2.

jchw 5y ago

Agreed regarding deprecation schedule. It’s hard to break old habits. However I do totally understand why, as a person who has more than once become ridiculously confused because I accidentally ran go get in a directory that was a Go module. Somehow I even managed to make my home directory a Go module, leading to a lot more confusion. Needless to say, they do need to fix that somehow. They probably should’ve gone the other direction and made a new go get command that was specific to modules. It’s a bit too late to do that now. Go modules overall have been reasonably smooth but I’m a bit disappointed since this particular break will cause a lot of confusion. I think most likely in the long term it will pay off, but it’s probably unnecessarily abrupt. Maybe this is being done to lead into Go 2? Honestly, I do have another wish: I wish there was a version of “go run” that could fetch, compile and run directly from the Internet. Now I realize that’s not particularly safe, but it’s not much unsafer than doing it in two steps, and man would it be slick for small demos.

floren 5y ago

I'm in favor of firming up the roles of `go get` and `go install`--it was damn weird that running `go get github.com/foo/bar` did one thing inside a Go project and another outside it. Growing pains of the introduction of Go modules and the deprecation of GOPATH and what-not. My bigger complaint, though, is that the Go team have decided to ignore replace directives when you call `go install`. In a perfect world, I find a bug in an upstream library, submit a fix, and they accept it. In practice, lots of upstream maintainers check their issue/PR lists about once a month if you're lucky, so the best way to temporarily fix the problem is to put in a replace directive changing github.com/foo/bar -> github.com/me/bar until the PR goes in. Except `go install` will ignore that, so if you install a tool via `go install` you get the broken library, but if you git clone the repo and run `go build`, you get the fix. In proper Go team fashion, they have declared that because sometimes replace directives are difficult, they refuse to deal with them at all--if you intend to distribute something for use with go install, you better fork the dependency and update all your source files.

pa7ch 5y ago
'go install pkg@version' will error on replace directives rather then ignore. I fought hard in the github issues to make go install error on replace as a compromise to ignoreing it which creates two subtly different build modes! Also by erroring we leave open the possibility to eventually change it to build correctly with the replace directives without breakage. Add your voice that @version cmds should respect all replace directives that they reasonably can!
- floren 5y ago
  Thank you for the correction, and thank you for fighting for it! I agree that errors are far better than silently ignoring it. I'll weigh in on the issue tracker if I remember later.
sudhirj 5y ago
In the interest of fairness, shouldn't this finish with: > In proper Go team fashion, they have declared that because sometimes replace directives are difficult,... they've asked for proposals that can be publicly vetted and discussed? The line has been "submit a proposal, let's review it" as long as I can remember.

xorvoid 5y ago

Idk.. the alternative seems like a Python 3 nightmare. People start depending on things and then you’re faced with two choices: (1) break lots of people, (2) hold on to every bit of ugly broken legacy stuff in the name of backwards compat. At this point, I feel like the entire solution space has been explored between all the different languages and there is not a great solution from any of them. Personally, I’m much happier with Go breaking things than becoming a C/C++ hole of legacy going back like 50+ years. On the timing and speed (only one version warning before removal): we can debate the right speed until the cows come home. But, Python 3 took longer than a decade to kill Python 2 as they were trying to give people “plenty of time”. In the end (IMHO), people don’t change unless they’re aggressively forced to because there is always something better to do with your time than upgrade software to prevent some possible future hypothetical breakage. That calculus changes when it’s not hypothetical at all.

ryandvm 5y ago
Agreed. Python 3 and IPv6 are case studies in how not to do an upgrade. While I can appreciate the care and engineering skill involved in upgrading a technology while still having backward compatibility, it turns out just to enable the worst possible behavior on the consumer end. I think I like Apple's way of just forcing breaking changes down everyone's throats (e.g. removing CD/DVD, PowerPC->x86, 30-pin->Lightning, dropping headphone port, etc.). Sure the tech media complain for a cycle, but then everybody adapts and the world's a better place.
- XorNot 5y ago
  There was literally no choice when it came to IPv6. Everyone who thinks they've got a clever compromise is forgetting that it's not a software problem where it matters.
  - drran 5y ago
    Embrace Extend Extinguish I vote for IPv5 protocol, which will allow to cal any IPv4 host via IPv5-IPv4 NAT transparently at nearest bridge. WHY I cannot do `ping6 127.0.0.1`? WTF? Is IPv6 is too small for whole IPv4 address space?

chucke 5y ago

> Yes, this approach is in some sense more correct; it's also less humane. It's robot logic (also).) Sums up the go philosophy to me. A machine-first language, forces developers to think like a computer.

morelisp 5y ago
We've had substantially more success at this than teaching computers to think like developers, so, sounds fine.

John23832 5y ago

The use of `go get` vs `go install` was always confusing to me. Especially with the release of modules. I say this is a change for the better. The cli is more consistent. The argument made in the post seems more like a philosophical "wah, wah, I don't want to".

pa7ch 5y ago
Agreed. They originally almost made this new cmd a special flag on go get leaving go get and install alone. Now they finally clearly do one thing each. Might be painful but its clean break for the better now.

thomasfedb 5y ago

There's value in delightfulness in CLI tools. Having "go get" be the incantation for Go to go and get something, that's a nice experience for a dev, particuarly when you're picking up the language/tooling.

dwheeler 5y ago

I agree with the author, that is a ridiculously short time for a breaking change in widely-used functionality. Every "update that breaks things" is teaching your users to not update the software, ever. Frankly, it's hurtful to users. By all means send the deprecation warning, but give a lot more time before removing the functionality. Tools require time to get widely distributed unless there's a huge emergency. In this case, there's no need for the hurry.

tonfreed 5y ago

Cool, but where are my generics?

gunapologist99 5y ago

This is not a deprecation of the language, or even a small part of the language, and it's certainly a lot less than dumping huge parts of an existing and functional language as we saw with python 3 and perl 6. This is simply changing the command-line options that you would do on a somewhat occasional basis, but it does not require changes to any code (except for, perhaps, installation shell scripts or install docs.) This does not infringe on the Go backwards-compatibility promise that attracted me to Go in the first place in any way, and it helps clarify a confusing situation. It's a win-win.

moondev 5y ago

I'm most excited about "go run" supporting import paths in 1.17, similar to how npx works for node

airhead969 5y ago

Lessons (not) learned: Go never worked well with semantic versioning or packaging, didn't mature and evolve as a language fast enough for productivity at scale in ways users wanted, became stuck in its ruts, and was overwhelmed by an influx of trend-following noobs. I bounced because its stiltedness never seemed to improve.

Thaxll 5y ago

tbh it's not really a breaking change, it's for getting binary, it has nothing to do with compiling Go code or the Go language itself. I don't remember the last time I had to to use go get to download a binary ( I'm using wget or curl for that ).

fnord123 5y ago

>The bigger thing is that this particular deprecation is probably going to mean that fewer people use utilities and other programs written in Go. There are quite a lot of open source programs written in Go out there that currently say to install them with 'go get ...' I can tell you that in the wild, non go programmers do not use tools installed using the go compiler that they do not have installed. It's apt, brew, $WINDOWS_PACKAGE_MANAGER, flatpak, etc. I imagine precious few people install docker or sysdig using `go get`.

omginternets 5y ago

I'm not sure what the issue is: 1. `go get` will work as expected when run from a directory with a go.mod (or have I misunderstood?) 2. Given the above, the argument about people who include `go get` in their GitHub READMEs makes little sense. Those who blindly copy `go get` from a README will quickly learn to run `go mod init` to set up their projects. 3. There is a deprecation warning, giving everyone plenty of time to adjust to these minimal changes. Where's the big deal? I'm reminded of this popular XKCD comic: https://xkcd.com/1172/ https://xkcd.com/1172/

geofft 5y ago

> The bigger thing is that this particular deprecation is probably going to mean that fewer people use utilities and other programs written in Go. I kept hearing this about Python 2->3, specifically in the context that people would start writing stuff in Go instead. And it was a little bit true, sure, but there's plenty of stuff that's still in Python that people still figure out how to use. So I'm deeply amused to hear that people are going to switch away from utilities written in Go and curious what language they're switching to.

skybrian 5y ago

If the error message is something decent like “please run ‘go install’ instead” then it seems like users are going to learn the new command rather than giving up? It might be more a problem if ‘go get’ is used to install commands in installer scripts.

hda111 5y ago

I don’t get why people use Go. It’s just an awful language without OOP and without FP. Looks like an ancient language compared to Rust.

dcow 5y ago

I might agree with the author if `go get` wasn't such a terrible and confusing command in the first place. It actively deceives users new to go now that modules are a thing because it does not do what you would expect if you are in a directory with a .mod file. Projects that list “go get” as the install method do not work in subtle and surprising ways for users new to the language, period. It’s 2021 go modules have been around for what 6 minor versions now? Flows have been convoluted (broken) for quite some time. The author fails to discuss the real issue and is simply pandering to some “but workflows might break” argument. If you have a workflow that depends on go get and you aren't using modules you will have at least months to update it to go install.

flyinprogrammer 5y ago

Plug for: https://github.com/goreleaser/goreleaser https://github.com/goreleaser/goreleaser https://github.com/goreleaser/godownloader https://github.com/goreleaser/godownloader

deleted 5y ago

[deleted]

phendrenad2 5y ago

How do we solve the problem of clueless maintainers breaking everyone's shit? How do we make them understand that their urge to homogenize and rectify and beautify all APIs is causing people anguish. Do they just not care?

jd3 5y ago

for everyone else that was confused about why an article titled > Go 1.17 is deprecating the traditional use of 'go get' did not link to the original proposal/implementation issues: initial proposal: https://github.com/golang/go/issues/40276 https://github.com/golang/go/issues/40276 1.16 deprecation delay: https://github.com/golang/go/issues/42885 https://github.com/golang/go/issues/42885 1.17 deprecation: https://github.com/golang/go/issues/43684 https://github.com/golang/go/issues/43684

anthk 5y ago

Why doesn't go build extra dependencies in the current directory instead of polluting $GOPATH/src ?

thiht 5y ago

> Go will be printing a warning for only one release, which means six months or so. Seems more than fair to me. Nothing to see here.