diff options
| -rw-r--r-- | content/go2-next-steps.article | 153 |
1 files changed, 153 insertions, 0 deletions
diff --git a/content/go2-next-steps.article b/content/go2-next-steps.article new file mode 100644 index 0000000..07f6abe --- /dev/null +++ b/content/go2-next-steps.article @@ -0,0 +1,153 @@ +Next steps toward Go 2 +26 Jun 2019 +Tags: go2, proposals, community + +Robert Griesemer, for the Go team + +* Status + +We’re well on the way towards the release of Go 1.13, +hopefully in early August of this year. +This is the first release that will include concrete changes +to the language (rather than just minor adjustments to the spec), +after a longer moratorium on any such changes. + +To arrive at these language changes, +we started out with a small set of viable proposals, +selected from the much larger list of +[[https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3AGo2+label%3AProposal][Go 2 proposals]], +per the new proposal evaluation process outlined +in the +“[[https://blog.golang.org/go2-here-we-come][Go 2, here we come!]]” blog post. +We wanted our initial selection of proposals +to be relatively minor and mostly uncontroversial, +to have a reasonably high chance of having them +make it through the process. +The proposed changes had to be backward-compatible +to be minimally disruptive since +[[https://blog.golang.org/using-go-modules][modules]], +which eventually will allow module-specific language version selection, +are not the default build mode quite yet. +In short, this initial round of changes was more about +getting the ball rolling again and gaining experience +with the new process, rather than tackling big issues. + +Our +[[https://blog.golang.org/go2-here-we-come][original list of proposals]] – +[[https://golang.org/issue/20706][general Unicode identifiers]], +[[https://golang.org/issue/19308][binary integer literals]], +[[https://golang.org/issue/28493][separators for number literals]], +[[https://golang.org/issue/19113][signed integer shift counts]] – +got both trimmed and expanded. +The general Unicode identifiers didn’t make the cut +as we didn’t have a concrete design document in place in time. +The proposal for binary integer literals was expanded significantly +and led to a comprehensive overhaul and modernization of +[[https://golang.org/design/19308-number-literals][Go’s number literal syntax]]. +And we added the Go 2 draft design proposal on +[[https://golang.org/design/go2draft-error-inspection][error inspection]], +which has been +[[https://golang.org/issue/29934#issuecomment-489682919][partially accepted]]. + +With these initial changes in place for Go 1.13, +it’s now time to look forward to Go 1.14 +and determine what we want to tackle next. + +* Proposals for Go 1.14 + +The goals we have for Go today are the same as in 2007: to +[[https://blog.golang.org/toward-go2][make software development scale]]. +The three biggest hurdles on this path to improved scalability for Go are +package and version management, +better error handling support, +and generics. + +With Go module support getting increasingly stronger, +support for package and version management is being addressed. +This leaves better error handling support and generics. +We have been working on both of these and presented +[[https://golang.org/design/go2draft][draft designs]] +at last year’s GopherCon in Denver. +Since then we have been iterating those designs. +For error handling, we have published a concrete, +significantly revised and simplified proposal (see below). +For generics, we are making progress, with a talk +(“Generics in Go” by Ian Lance Taylor) +[[https://www.gophercon.com/agenda/session/49028][coming up]] +at this year’s GopherCon in San Diego, +but we have not reached the concrete proposal stage yet. + +We also want to continue with smaller +improvements to the language. +For Go 1.14, we have selected the following proposals: + +[[https://golang.org/issue/32437][#32437]]. +A built-in Go error check function, “try” +([[https://golang.org/design/32437-try-builtin][design doc]]). + +This is our concrete proposal for improved error handling. +While the proposed, fully backwards-compatible language extension +is minimal, we expect an outsize impact on error handling code. +This proposal has already attracted an enormous amount of comments, +and it’s not easy to follow up. +We recommend starting with the +[[https://golang.org/issue/32437#issue-452239211][initial comment]] +for a quick outline and then to read the detailed design doc. +The initial comment contains a couple of links leading to summaries +of the feedback so far. +Please follow the feedback recommendations +(see the “Next steps” section below) before posting. + +[[https://golang.org/issue/6977][#6977]]. +Allow embedding overlapping interfaces +([[https://golang.org/design/6977-overlapping-interfaces][design doc]]). + +This is an old, backwards-compatible proposal for making interface embedding more tolerant. + +[[https://golang.org/issue/32479][#32479]] Diagnose `string(int)` conversion in `go`vet`. + +The `string(int)` conversion was introduced early in Go for convenience, +but it is confusing to newcomers (`string(10)` is `"\n"` not `"10"`) +and not justified anymore now that the conversion is available +in the `unicode/utf8` package. +Since removing this conversion is not a backwards-compatible change, +we propose to start with a `vet` error instead. + +[[https://golang.org/issue/32466][#32466]] Adopt crypto principles +([[https://golang.org/design/cryptography-principles][design doc]]). + +This is a request for feedback on a set of design principles for +cryptographic libraries that we would like to adopt. +See also the related +[[https://golang.org/issue/32716][proposal to remove SSLv3 support]] +from `crypto/tls`. + +* Next steps + +We are actively soliciting feedback on all these proposals. +We are especially interested in fact-based evidence +illustrating why a proposal might not work well in practice, +or problematic aspects we might have missed in the design. +Convincing examples in support of a proposal are also very helpful. +On the other hand, comments containing only personal opinions +are less actionable: +we can acknowledge them but we can’t address them +in any constructive way. +Before posting, please take the time to read the detailed +design docs and prior feedback or feedback summaries. +Especially in long discussions, your concern may have already +been raised and discussed in earlier comments. + +Unless there are strong reasons to not even proceed into the +experimental phase with a given proposal, +we are planning to have all these implemented at the +start of the +[[https://golang.org/wiki/Go-Release-Cycle][Go 1.14 cycle]] +(beginning of August, 2019) +so that they can be evaluated in practice. +Per the +[[https://blog.golang.org/go2-here-we-come][proposal evaluation process]], +the final decision will be +made at the end of the development cycle (beginning of November, 2019). + +Thank you for helping making Go a better language! |