Go proposes two rounds of feedback for language changes

A language can accumulate proposals faster than it can responsibly adopt them. Go has a particular reason to be selective because existing programs and their maintainers depend on compatibility. Robert Griesemer's November 29 process announcement gives significant changes a path through evaluation without making an initial selection equivalent to acceptance.

The announcement also clarifies what Go 2 means in this discussion. The name describes a future language reached through incremental steps. It does not announce one release in which all accumulated proposals arrive together. That distinction gives the project a way to examine independent changes without tying each one to an undefined wholesale transition.

I value Go's restraint because understanding somebody else's code should not require learning a new collection of optional mechanisms every year. Restraint still needs a process for examining real shortcomings. Otherwise, compatibility can become a reason to defer every difficult decision without learning whether a limited change would help.

Selection leaves room for rejection

The process begins with the team choosing a small set of proposals worth considering. A public announcement then invites feedback on that tentative direction. Implementation follows the feedback, with the intention that the changes be ready at the beginning of a development cycle. Availability in the implementation provides another opportunity for people to examine them.

The final shipping decision comes after that development experience. A proposal can reach implementation and still be removed. That makes the experiment meaningful because the project has not committed to shipping before seeing how the implementation behaves in use.

There is an engineering consequence to preserving that option. The announcement says implementations need to allow a feature to be disabled without destabilizing the rest of the system. An experiment that becomes inseparable from unrelated work would make removal costly. The organization of the implementation therefore supports the credibility of the decision process.

Two feedback stages answer different questions. Before implementation, participants can identify conceptual problems or explain how a proposal interacts with their code. After implementation, they can report what actually happens when they try it. A written argument can be persuasive while leaving practical costs undiscovered. The later stage supplies evidence that discussion alone cannot provide.

The process also narrows the discussion to selected changes. Reviewing a small set gives participants a concrete implementation and a defined decision to examine. It avoids treating the entire collection of outstanding ideas as one indivisible language redesign.

The criteria include people who do not need the feature

Griesemer identifies broad usefulness and limited disruption as selection requirements. A proposal must also have a clear solution that the project understands how to implement. These requirements make popularity insufficient by itself. A desirable capability can remain outside this process while its design is unsettled.

That last condition explains the status of generics in the announcement. The team recognizes a substantial problem but does not yet consider the solution sufficiently understood. An August draft-design announcement invited feedback on preliminary error-handling and generics designs. The existence of those drafts does not mean that either design has become a released language feature.

The distinction is useful for application authors reading a roadmap. A topic can be important enough to study without having a settled syntax or implementation. Code written against an imagined final design would depend on decisions the project has not made. The current process provides places to contribute evidence while preserving that uncertainty.

Limited impact also means considering programmers who have no use for a proposal. A feature can impose costs through changed syntax, tooling work, or additional concepts that readers must recognize. Evaluating it requires examining those costs alongside the code it improves. This is an implication of the criteria, rather than a claim that every addition carries the same burden.

I find that requirement particularly consistent with Go's appeal. The people reading an unfamiliar package inherit the language choices its author makes. A convenience for the writer deserves scrutiny when it adds work for every later reader.

Small proposals will exercise the process

The initial selection includes broader Unicode identifiers, binary integer literals and separators in numeric literals, and signed integer shift counts. The announcement presents these as candidates for a future release. Their selection starts the feedback process and does not make the proposed forms legal in today's Go compiler.

Each proposal examines a different kind of friction. Identifier rules concern which names programmers can express directly. Numeric notation concerns how a programmer communicates a constant's structure. Shift counts concern conversions that existing source needs to satisfy the language's typing rules. These are bounded subjects compared with a complete design for generic programming.

Their limited scope also gives feedback a more specific target. A participant can explain a normalization problem for identifiers or identify how a proposed shift rule interacts with existing code. That kind of report is more actionable than a broad preference for a smaller or larger language. It links the argument to a consequence the implementation can examine.

No code example of the proposed new syntax should be mistaken for a recommendation to use it now. Existing applications continue to target the released language. The relevant work at this stage is reviewing the proposal and, when an implementation is available, examining whether it meets the stated goal without unacceptable disruption.

Implementation experience informs a separate decision

The announcement describes the process as a starting point that will itself need adjustment. That is consistent with its structure. The team can learn both whether a feature works and whether the evaluation stages produce enough useful evidence. Neither result is established merely by publishing the plan.

For contributors, the immediate action is to provide feedback on the selected proposal issues. A useful response can identify code affected by a rule or explain an implementation concern precisely enough for others to investigate. The process then preserves another decision point after the implementation has been tried. A selected proposal remains provisional until the project makes that final decision, and its implementation needs to remain removable throughout the experiment.