Next steps toward Go 2

Next steps toward Go 2

26 June 2019

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

Go 2 proposals,

per the new proposal evaluation process outlined

in the

“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

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

original list of proposals –

general Unicode identifiers,

binary integer literals,

separators for number literals,

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

Go’s number literal syntax.

And we added the Go 2 draft design proposal on

error inspection,

which has been

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

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

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)

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:

#32437.

A built-in Go error check function, “try”

(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

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.

#6977.

Allow embedding overlapping interfaces

(design doc).

This is an old, backwards-compatible proposal for making interface embedding more tolerant.

#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.

#32466 Adopt crypto 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

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

Go 1.14 cycle

(beginning of August, 2019)

so that they can be evaluated in practice.

Per the

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!

By Robert Griesemer, for the Go team