Original text: blog.golang.org/go2-next-st…
The status quo
We’ll be releasing Go 1.13 in August 2019 if nothing goes wrong. This is the first real change (as opposed to regulatory tweaks) to the Go language that has long been proposed but has been delayed.
To implement the language change, we followed the “Go 2, here we come!” The assessment process in the document starts with a small number of proposals that are feasible from Go 2 proposals (the Go 2 Proposals list).
We wanted our initial selection of proposals to be relatively small, with little controversy, to make it more likely that these changes would be implemented. Proposals for these “changes” must be backward compatible to minimize damage to modules that allow the Go language version to be specified rather than the default build. In short, as the first round of changes, it is mainly for the accumulation of iterative experience, rather than to solve major problems.
Proposals trimmed and expanded from the original proposal list:
Binary Integer literals Separators for number literals Since we did not produce the specific design document for the “Common Unicode Identifiers” proposal in time, we left it unmodified. The proposal for “binary integer literals” has been significantly expanded and the digital text syntax of Go has been completely reformed and modernized. We added the Go 2 draft design to the error check, which has been partially accepted.
After these initial changes to Go 1.13, it’s time to look forward to Go 1.14 and determine what issues we’ll tackle next.
Go 1.14 related proposal
True to its roots, Go’s goal is the same as it was in 2007: to scale software development. However, “package versioning”, “error handling” and “generics” are three major issues that have hindered the development of Go.
As the Go Module became more and more supported, we solved the management of packages and package versions, leaving “error handling” and “generics” among the top three problems.
We have been working hard on both of these issues and showed draft Designs at GopherCon in Denver last year and have been iterating.
In terms of error handling, we released a specific, significantly revised and simplified proposal (which will be discussed below).
We’re still working on generics. There was a talk about it coming up at This year’s GopherCon in San Diego (” Generics in Go “by Ian Lance Taylor) but we don’t have a concrete proposal yet.
We also hope to continue making small improvements. For the Go1.14 release, we have selected the following proposals:
#32437. Built-in error handler, “try” (Design doc).
This is a concrete proposal to improve the error handling mechanism. This proposal has weak backward compatibility, but we hope it will greatly improve the way errors are handled. The proposal has already attracted a lot of feedback, so it’s not easy to follow up. We recommend starting with initial comment for a quick overview and then reading the detailed design document. This initial comment includes several links to a summary of the feedback to date. If you want to submit feedback, please follow the feedback suggestions before submitting (see the “Next Steps” section below).
#6977. Allow nested interfaces (Design Doc).
Allowing nested interfaces is an old proposal, and a backward compatible one.
#32479 Go Vet diagnostic string(int) conversion
The String (int) conversion was introduced early in the Go language for convenience, but it can be confusing for beginners (string(10) converts to “\n” instead of “10”) and doesn’t make sense today when Unicode/UTF8 packages are available. However, removing this transformation would result in backward incompatibility, so we recommend using VET to diagnose errors first.
#32466 Adopt encryption principles (Design Doc)
This is feedback on a set of design principles for the cryptographic library we want to adopt. See also the crypto/ TLS proposal to remove SSLv3 support.
Subsequent steps
We are actively seeking feedback on these proposals. We are particularly interested in fact-based evidence, please indicate in your feedback why the proposal may not work well in practice, or issues we may have missed in the design.
If you support a proposal, it’s also useful to have a compelling case.
On the other hand, please don’t post questions that contain only personal factors: we understand that, but we can’t solve it in any constructive way.
Before Posting feedback, take the time to read the detailed design document and previous feedback or summary of feedback. In particular, these proposals have been discussed for a long time, and your concerns may have been raised and discussed in the early comments.
Unsurprisingly, we plan to start implementing all of these proposals in Go 1.14 (early August 2019) so that we can evaluate them in practice (practice is the test of all truths). According to the proposal evaluation process, a final decision will be made towards the end of the development cycle (early November 2019).
Thank you for helping make Go a better language!