diff options
| -rw-r--r-- | content/go2-here-we-come.article | 205 |
1 files changed, 205 insertions, 0 deletions
diff --git a/content/go2-here-we-come.article b/content/go2-here-we-come.article new file mode 100644 index 0000000..0f749de --- /dev/null +++ b/content/go2-here-we-come.article @@ -0,0 +1,205 @@ +Go 2, here we come! +29 Nov 2018 +Tags: go2, proposals, community + +Robert Griesemer + +* Background + +At GopherCon 2017, Russ Cox officially started the thought process on the +next big version of Go with his talk [[https://www.youtube.com/watch?v=0Zbh_vmAKvk][The Future of Go]] +([[https://blog.golang.org/toward-go2][blog post]]). We have +called this future language informally Go 2, even though we understand now +that it will arrive in incremental steps rather than with a big bang and a +single major release. Still, Go 2 is a useful moniker, if only to have a way +to talk about that future language, so let’s keep using it for now. + +A major difference between Go 1 and Go 2 is who is going to influence the +design and how decisions are made. Go 1 was a small team effort with modest +outside influence; Go 2 will be much more community-driven. +After almost 10 years of exposure, we have +learned a lot about the language and libraries that we didn’t know in the +beginning, and that was only possible through feedback from the Go community. + +In 2015 we introduced the [[https://golang.org/s/proposal][proposal process]] +to gather a specific kind of feedback: proposals for language and library +changes. A committee composed of senior Go team members has been reviewing, +categorizing, and deciding on incoming proposals on a regular basis. That +has worked pretty well, but as part of that process we have ignored all +proposals that are not backward-compatible, simply labeling them Go 2 instead. +In 2017 we also stopped making any kind of incremental backward-compatible +language changes, however small, in favor of a more comprehensive plan that +takes the bigger picture of Go 2 into account. + +It is now time to act on the Go 2 proposals, but to do this we first need a plan. + +* Status + +At the time of writing, there are around 120 +[[https://github.com/golang/go/issues?page=1&q=is%3Aissue+is%3Aopen+label%3Aproposal+label%3AGo2&utf8=%E2%9C%93][open issues labeled Go 2 proposal]]. +Each of them proposes a significant library or language change, often one +that does not satisfy the existing +[[https://golang.org/doc/go1compat][Go 1 compatibility guarantee]]. +Ian Lance Taylor and I +have been working through these proposals and categorized them +([[https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Aproposal+label%3AGo2+label%3AGo2Cleanup][Go2Cleanup]], +[[https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Aproposal+label%3AGo2+label%3ANeedsDecision][NeedsDecision]], +etc.) to get an idea of what’s there and to make it easier to +proceed with them. We also merged related proposals and closed the ones which +seemed clearly out of the scope of Go, or were otherwise unactionable. + +Ideas from the remaining proposals will likely influence Go 2’s libraries +and languages. Two major themes have emerged early on: support for better +error handling, and generics. [[https://blog.golang.org/go2draft][Draft designs]] +for these two areas have been +published at this year’s GopherCon, and more exploration is needed. + +But what about the rest? We are [[https://blog.golang.org/toward-go2][constrained]] +by the fact that we now have +millions of Go programmers and a large body of Go code, and we need to +bring it all along, lest we risk a split ecosystem. That means we cannot +make many changes, and the changes we are going to make need to be chosen +carefully. To make progress, we are implementing a new proposal evaluation +process for these significant potential changes. + +* Proposal evaluation process + +The purpose of the proposal evaluation process is to collect feedback on +a small number of select proposals such that a final decision can be made. +The process runs more or less in parallel to a release cycle and consists +of the following steps: + +1. _Proposal_selection_. The Go team selects a small number of +[[https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3AGo2+label%3AProposal][Go 2 proposals]] +that seem worth considering for acceptance, without making a final decision. +See below for more on the selection criteria. + +2. _Proposal_feedback_. The Go team sends out an announcement listing the selected +proposals. The announcement explains to the community the tentative intent to +move forward with the selected proposals and to collect feedback for each +of them. This gives the community a chance to make suggestions and express +concerns. + +3. _Implementation_. Based on that feedback, the proposals are implemented. +The target for these significant language and library changes is to have +them ready to submit on day 1 of an upcoming release cycle. + +4. _Implementation_feedback_. During the development cycle, the Go team and +community have a chance to experiment with the new features and collect +further feedback. + +5. _Launch_decision_. At the end of the three month +[[https://github.com/golang/go/wiki/Go-Release-Cycle][development cycle]] +(just when starting the three month repo freeze before a release), and +based on the experience and feedback gathered during the release cycle, +the Go team makes the final decision about whether to ship each change. +This provides an opportunity to consider whether the change has delivered +the expected benefits or created any unexpected costs. Once shipped, the +changes become part of the language and libraries. Excluded proposals may +go back to the drawing board or may be declined for good. + +With two rounds of feedback, this process is slanted towards declining +proposals, which will hopefully prevent feature creep and help with +keeping the language small and clean. + +We can’t go through this process for each of the open Go 2 +proposals, there are simply too many of them. That’s where the selection +criteria come into play. + +* Proposal selection criteria + +A proposal must at the very least: + +1. _address_an_important_issue_for_many_people_, + +2. _have_minimal_impact_on_everybody_else_, and + +3. _come_with_a_clear_and_well-understood_solution_. + +Requirement 1 ensures that any changes we make help as many Go developers +as possible (make their code more robust, easier to write, more likely to +be correct, and so on), while requirement 2 ensures we are careful to hurt +as few developers as possible, whether by breaking their programs or causing +other churn. As a rule of thumb, we should aim to help at least ten times as +many developers as we hurt with a given change. Changes that don't affect +real Go usage are a net zero benefit put up against a significant +implementation cost and should be avoided. + +Without requirement 3 we don’t have an implementation of the proposal. +For instance, we believe that some form of genericity might solve an important +issue for a lot of people, but we don’t yet have a clear and well-understood +solution. That’s fine, it just means that the proposal needs to go back to +the drawing board before it can be considered. + +* Proposals + +We feel that this is a good plan that should serve us well but it is important +to understand that this is only a starting point. As the process is used we will +discover the ways in which it fails to work well and we will refine it as needed. +The critical part is that until we use it in practice we won't know how to improve it. + +A safe place to start is with a small number of backward-compatible language +proposals. We haven’t done language changes for a long time, so this gets us +back into that mode. Also, the changes won’t require us worrying about +breaking existing code, and thus they serve as a perfect trial balloon. + +With all that said, we propose the following selection of Go 2 proposals for +the Go 1.13 release (step 1 in the proposal evaluation process): + +1. [[https://github.com/golang/go/issues/20706][_#20706_]] _General_Unicode_identifiers_based_on_ [[http://unicode.org/reports/tr31/][_Unicode_TR31_]]: +This addresses an important issue for Go programmers using non-Western alphabets +and should have little if any impact on anyone else. There are normalization +questions which we need to answer and where community feedback will be +important, but after that the implementation path is well understood. +Note that identifier export rules will not be affected by this. + +2. [[https://github.com/golang/go/issues/19308][_#19308_]], [[https://github.com/golang/go/issues/28493][_#28493_]] _Binary_integer_literals_and_support_for___in_number_literals_: +These are relatively minor changes that seem hugely popular among many +programmers. They may not quite reach the threshold of solving an +“important issue” (hexadecimal numbers have worked well so far) but they +bring Go up to par with most other languages in this respect and relieve +a pain point for some programmers. They have minimal impact on others who +don’t care about binary integer literals or number formatting, and the +implementation is well understood. + +3. [[https://github.com/golang/go/issues/19113][_#19113_]] _Permit_signed_integers_as_shift_counts_: +An estimated 38% of all non-constant shifts require an (artificial) uint +conversion (see the issue for a more detailed break-down). This proposal +will clean up a lot of code, get shift expressions better in sync with index +expressions and the built-in functions cap and len. It will mostly have a +positive impact on code. The implementation is well understood. + +* Next steps + +With this blog post we have executed the first step and started the second +step of the proposal evaluation process. It’s now up to you, the +Go community, to provide feedback on the issues listed above. + +For each proposal for which we have clear and approving feedback, we will +move forward with the implementation (step 3 in the process). Because we +want the changes implemented on the first day of the next release cycle +(tentatively Feb. 1, 2019) we may start the implementation a bit early +this time to leave time for two full months of feedback (Dec. 2018, +Jan. 2019). + +For the 3-month development cycle (Feb. to May 2019) the chosen features +are implemented and available at tip and everybody will have a chance to +gather experience with them. This provides another opportunity for feedback +(step 4 in the process). + +Finally, shortly after the repo freeze (May 1, 2019), the Go team makes the +final decision whether to keep the new features for good (and include them +in the Go 1 compatibility guarantee), or whether to abandon them (final +step in the process). + +(Since there is a real chance that a feature may need to be removed just +when we freeze the repo, the implementation will need to be such that the +feature can be disabled without destabilizing the rest of the system. +For language changes that may mean that all feature-related code is +guarded by an internal flag.) + +This will be the first time that we have followed this process, hence the +repo freeze will also be a good moment to reflect on the process and to +adjust it if necessary. Let’s see how it goes. + +Happy evaluating! |