I rebuilt a March programme with a newer Go checkout today and it compiled unchanged. Six weeks ago that would not have been remarkable in most languages. After a year of weekly snapshots, it felt almost suspicious.

The practical test was modest:

$ go test example.org/...

I wanted source written for Go 1 and its standard packages to keep building as Go 1 implementations advance. That is the central value of the compatibility promise: users can update the toolchain for fixes and improvements without scheduling a language migration for ordinary conforming source.

My surprise was how much this changes maintenance planning. Before Go 1, I treated the compiler version as part of each source branch because language and package changes could require gofix. Under the Go 1 promise, the source version becomes a much less active participant. Tests still matter, but routine upgrades should not begin with syntax archaeology.

Compatibility applies to specified source behaviour and the documented standard library, not every observation a programme can make. Compiler diagnostics can improve. Binary formats, object files, and internal runtime structures can change. Performance can move in either direction. A programme depending on an undocumented detail has discovered a detail, not negotiated an additional promise.

Operating systems and external C libraries remain outside that promise as well. A cgo package can fail after a system header changes even when its Go source is perfectly compatible. Data formats and network protocols need their own stability policies. Go 1 cannot sign contracts on behalf of the rest of the machine.

I prefer writing against exported, documented APIs and testing behaviour rather than implementation trivia. If I inspect an internal representation for education or performance work, I label it with the exact toolchain and do not turn it into application logic. That keeps implementation freedom available to the people improving the compiler and runtime.

The caveat is bugs. Preserving an accidental result forever can be worse than correcting it, and the compatibility documentation leaves room for necessary fixes and clarifications. Security and correctness do not become subordinate to an interesting old mistake. Release notes remain worth reading.

This promise may be the least glamorous feature in Go 1, but it compounds. Every package that continues to build is time not spent on mandatory churn. My test command produced no story at all, which is exactly the story compatibility is supposed to produce.