Chris's Wiki :: blog/programming/GoAndDeprecatingGoGet

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

June 24, 2021

A change recently landed in the development version of Go, and will be in Go 1.17, with the title of doc/go1.17: note deprecation of 'go get' for installing commands. The actual updated documentation (from the current draft release notes) says:

go get prints a deprecation warning when installing commands outside the main module (without the -d flag). go install cmd@version should be used instead to install a command at a specific version, using a suffix like @latest or @v1.2.3. In Go 1.18, the -d flag will always be enabled, and go get will only be used to change dependencies in go.mod.

I have some views on this. The first one is that this is a pretty abrupt deprecation schedule. Go will be printing a warning for only one release, which means six months or so. People who don't update to every Go version (or their operating system's packaged version doesn't) will go from 'go get' working normally to install programs to having it fail completely.

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 ...' in their READMEs and other resources. Starting with Go 1.18, that's going to fail with some sort of error message. Some of these programs are actively still being developed and maintained, and perhaps will update their documentation to talk about 'go install'. Others are effectively inactive and will not update, so in the future anyone following their instructions will fail and will probably give up, despite the program still being perfectly good.

(There's probably also general documentation out on the Internet that talks about using 'go get' to install Go programs, and that's also going to be inaccurate. Hopefully none of them turn up high on search engine results for how to install Go programs.)

On a philosophical level, I'm unhappy with Go deciding that it's going to rapidly discard something that was the way to do things for years and then probably the dominant way for several more years. Years of use build up a lot of momentum; the Go developers want that momentum to shift in months, in what is now a large community. People don't shift that fast, and I think the result is likely to be confusing and annoying people for quite some time.

(This is also in some sense a pointless shift. The Go developers could as well say that plain 'go get' would become an alias for 'go install ...@latest', instead of breaking it entirely. Yes, this approach is in some sense more correct; it's also less humane. It's robot logic (also).)

Comments on this page:

By Aristotle Pagaltzis at 2021-06-25 01:47:26:

That timescale is obviously absurdly rapid, but I feel it wouldn’t have to be hugely protracted if at least it failed with a “did you want to do this other thing instead?” error – ideally forever. I gather that’s not the plan? If not, would that approach mollify you?

By cks at 2021-06-25 14:38:02:

I don't know what the long term plan is for the error message. One reason for uncertainty is that the error could plausibly be either 'you're trying to install a Go program in the old way' or 'you're trying to add a module dependency but you don't seem to be inside a Go module', since 'go get ...' can be used for either. Sooner or later the Go people might want to stop considering the first error at all.

Even with the error message staying for a long time, the short transition gives people little time to learn the new way, adjust their behavior, and update documentation (or persuade other people to do so). And if you don't update to Go 1.17 immediately, you have even less time for all of this. And if you miss the transition (or documentation doesn't get updated), all of this creates extra friction for using Go to install programs even if there's an error message to tell people what to do next.

This probably won't affect regular developers very much. It might not even affect me (although now there's not going to be any simple method to find the source repo of a Go program and clone it). But even for people who use Go regularly, that we have to mentally translate a README instruction of 'go get ...' into 'go install ...@latest' is a little bit of new friction.

By Aristotle Pagaltzis at 2021-06-25 19:39:05:

Undeniably there will be friction – but that seems a given for any change they were going to make here, no? Do you think they should leave alone entirely? Could that work in the long run? If not, that would just leave the question of how to manage the friction well.

(Which for a change this fundamental is obviously not “it will be removed completely one release from now”. I mean I would have considered it moving fast and breaking things if they’d proposed to remove it two releases down the line – that their actually opening bid is even sooner is… remarkable.)

Sooner or later the Go people might want to stop considering the first error at all.

The question should of course be whether users are making this error, not how the Go people feel about it…

By Russ Cox at 2021-06-26 08:29:14:

I appreciate you taking the time to share your concerns. Thank you.

I've posted a longish reply on Lobsters: https://lobste.rs/s/jb9mho/go_1_17_is_deprecating_traditional_use_go#c_xzldct.

Written on 24 June 2021.

«	I like WireGuard partly because it doesn't have 'sessions'

A couple of Linux top-like programs for network traffic »

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

Comments on this page:

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