Fundamentals 9 min read

Go 2.0 Is Coming: Inside the New Proposal Evaluation Process

After five years of dormancy, Go 2.0 is finally arriving, and the Go team has unveiled a community‑driven proposal evaluation process that outlines how selected language and library changes—such as generics, error handling, Unicode identifiers, and binary literals—will be reviewed, implemented, and potentially released.

21CTO
21CTO
21CTO
Go 2.0 Is Coming: Inside the New Proposal Evaluation Process

After five years of dormancy, Go Language 2.0 is finally on the horizon. In August the Go team released a design draft focusing on error handling and generics, and now they announce that it is time to move forward.

Unlike Go 1, which was created by a small core team, Go 2 will be shaped more heavily by the community, reflecting a broader decision‑making process.

Roughly 120 unresolved issues have been marked as Go 2 proposals, each tied to important libraries or language changes that may break Go 1 compatibility. These proposals are categorized (e.g., Go2Cleanup, NeedsDecision) to guide their execution.

Proposal Evaluation Process

The process aims to gather feedback on a small set of selected proposals while running in parallel with the release cycle. It consists of five steps:

Proposal Selection : The Go team picks a limited number of proposals that appear worthy of consideration.

Proposal Feedback : An announcement lists the chosen proposals, explains the team’s intent, and solicits community comments.

Implementation : Based on feedback, the proposals are implemented, with the goal of submitting the changes at the start of the next release cycle.

Implementation Feedback : During the development cycle, both the team and the community test the new features and provide further feedback.

Launch Decision : At the end of the three‑month cycle, the team decides whether to ship each change. Accepted changes become part of the language; rejected ones may be redrafted or permanently dropped.

Two rounds of feedback act as a filter, preventing feature creep and helping keep the language concise.

Proposal Selection Criteria

A proposal must satisfy three conditions:

It solves a problem that most users consider important.

It does not cause significant disruption to other users.

It offers a clear and understandable solution.

Condition 1 ensures that changes benefit as many Go developers as possible, making code more robust and easier to write. Condition 2 minimizes inconvenience for the minority affected. If condition 3 is not met, the proposal is rejected until a clear implementation plan is provided.

Sample Proposals

The team believes the upcoming updates will efficiently serve users, though they are just a starting point. Notable proposals include:

#20706 – Universal Unicode identifiers based on Unicode TR31, addressing a critical issue for developers using non‑Latin scripts while having minimal impact on others.

#19308 and #28493 – Binary integer literals and support for numeric literals, small changes that many developers welcome because they align Go with most other languages and solve existing pain points.

#19113 – Allow signed integers as shift counts, simplifying code where non‑constant shifts currently require explicit uint conversion.

Next Steps

The Go community is now invited to provide feedback on the above proposals. The team aims to ship the approved changes at the start of the next release cycle (tentatively February 1 2019), allowing a two‑month feedback window (December 2018 – January 2019).

A three‑month development period (February – May 2019) will see the selected features gradually rolled out, with additional opportunities for user feedback. After a short freeze period ending May 1 2019, the team will make a final decision: permanently retain the new features with Go 1 compatibility, or discard them.

This will be the first time the Go team employs this structured evaluation process, using the freeze period to reflect on and adjust the workflow as needed.

Stay tuned!

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

GenericsError Handlinglanguage designGo 2proposal evaluation
21CTO
Written by

21CTO

21CTO (21CTO.com) offers developers community, training, and services, making it your go‑to learning and service platform.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.