Changes to Go and the appearance of finality

August 13, 2019

In Thinking about about the Go Proposal Process, Russ Cox says the following about changes to Go in "Prototypes & Experiments":

For most non-trivial changes it is helpful to understand them by trying them out before making a decision. [...] We arrange to land language changes on day 1 of a development cycle to maximize that window. But for large changes we probably need a way to make prototypes available separately, to give even more time, a bit like the vgo prototype for Go modules.

I have a reaction to this and some opinions.

When the Go team lands language changes in the development version of Go, the default state of affairs at least appears to be that the change will be in the next release of Go, because after all it's in the development version. The Go team does not usually 'try things out' in the development tree; what lands in public is high quality and is almost always going to go into the next release unless some real problem is discovered and it has to be reverted. If the language changes are currently contentious and people disagree over them, landing them creates the impression that these changes are now a mostly done deal. This is especially the case if they land early, where other changes may come to depend on them (complicating a reversion), including changes other people make to tools and code to prepare for the next release of Go.

If the Go team does not mean this, I think that they should take steps to separate the regular development version, with its steady march toward release, from language changes that are being published so that people can try them out. One way to do this would be to land these changes in a separate tree, one based on the current release. As an additional bonus, this would allow people to try out the language changes without having to also take all of the other changes and uncertainties inherent in using a development version that's in flux, which might get more people to try them out.

(There have been times when other changes in the development version broke things like common editor tooling, making it hard to actually use the development version in anything like a normal environment.)

Another way to do this would be to require people to use a flag (perhaps a build option) to enable the language changes in the development version until at least part way through the process. This could create a stronger separation between changes that are clearly on course to be released and changes that are explicitly considered more experimental, while at the same time partially avoiding problems from merging significant changes late in the development cycle. There is some precedent for this approach already, with things like $GO111MODULE.

(Landing language changes in a separate tree doesn't preclude them from also landing in the development tree, so you could do both at once. If the Go team does, I think that language changes in the development tree should still default to off for part of the development cycle.)

This isn't something that's necessary on a technical level, or even a procedural one, since in the past the Go team has reversed itself and reverted features late in the Go development cycle because they weren't ready. But for contentious changes, I think it is very much called for, because appearances matter and the current appearance of things tilts fairly strongly in one direction.

PS: As an indication of how the Go team and language changes are viewed today, the dropping of try() was a genuine surprise to me and I think a decent number of other people, despite the significant amount of disagreement that had been expressed about it (cf, which I wrote almost as the proposal was being dropped).

Written on 13 August 2019.
« Linux can run out of memory without triggering the Out-Of-Memory killer
Getting LSP-based editing working for Go in GNU Emacs »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Aug 13 23:32:37 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.