Go 1.9 beta makes compatibility claims testable
The first beta exposes type aliases, monotonic time, and parallel compilation for testing. Its tagged source also records a bootstrap failure found while preparing the release.
The commit selected for the first Go 1.9 beta fixes a problem in producing a compiler distribution. A version check intended to keep the Go command and compiler consistent was too aggressive during bootstrapping. The problem had remained unnoticed because the development tree did not contain the version file that exposed it. Preparing a release exercised a path that ordinary development had missed.
The go1.9beta1 tag points to that June 14 commit. Its message says the release builder catches the problem and records a reproduction using a VERSION file and make.bash. This is a useful introduction to a beta. Producing the distribution is itself a test of assumptions that can remain hidden while the source tree changes.
The release notes preserved in the beta explicitly describe themselves as work in progress. They say Go 1.9 is not yet released and is expected in August. The correct reading is therefore a set of changes available for evaluation, with compatibility expectations to check, rather than a completed stable release.
Compatibility reaches beyond parsing
The draft notes retain the Go 1 compatibility promise and expect almost all programs to compile and run as before. That statement covers a wider area than whether old syntax still parses. Programs also depend on library behavior and on implementation assumptions surrounding clocks, compilation, and debugging.
One proposed change makes duration calculations robust against wall-clock adjustments. The beta notes say time.Time now tracks monotonic time transparently, allowing duration calculations between time values to remain safe when wall time changes. A timestamp used for elapsed time has a different purpose from a timestamp used to name a civil instant. Making the distinction internal allows ordinary code to benefit without introducing another common timing idiom.
This is exactly the kind of change that benefits from real application testing. Existing source may continue compiling while its interactions with time values exercise cases absent from a small example. The beta gives users a concrete implementation to evaluate alongside the stated contract.
I favor improvements that preserve a readable application-level expression. A duration calculation should not require every caller to invent a separate clock abstraction merely to avoid a wall-clock adjustment. The beta makes that design choice available for examination before the stable release.
Type aliases support a staged move
The language addition in the beta is type aliases. The notes describe their purpose as gradual repair while moving a type between packages. An alias declaration gives another name to the same type.
type T1 = T2
That equality is the point of the syntax. If a package moves a type while callers migrate at different times, two names must be able to identify the same type during the transition. A new name that creates a distinct type would not supply that property.
The change targets a practical maintenance problem in a language that values explicit package boundaries. Moving a definition can affect users outside the package making the change. An alias provides an intermediate state in which old and new references can coexist, giving a refactoring a sequence of smaller steps.
The beta status matters here too. These notes describe the available mechanism, and downstream packages can try realistic moves against it. The event is the availability of that testing opportunity, not evidence that every refactoring pattern has already been validated.
Parallelism inside the compiler
Go already compiles separate packages in parallel. The beta adds parallel compilation of functions within a package. This is a separate source of concurrency, which matters when a build contains a package large enough that package-level scheduling leaves available cores unused.
The draft notes say the new behavior is on by default and can be disabled with GO19CONCURRENTCOMPILATION=0. That gives a concrete way to distinguish a compiler failure related to concurrent compilation from a failure that occurs with either setting. It is a diagnostic control for the new implementation, not a requirement for application source changes.
The tag itself illustrates why toolchain testing needs realistic build paths. The version-consistency check failed under bootstrap conditions involving the release version file. Testing only an installed compiler against one small application would not reproduce the distribution-building step described in the commit.
Runtime and test-library changes
The draft also changes explicitly requested garbage collection. Calls through runtime.GC, debug.SetGCPercent, and debug.FreeOSMemory now trigger concurrent collection, blocking the calling goroutine until completion. The distinction between blocking one caller and stopping execution across the program is central to understanding that change.
Test helpers gain a smaller but useful addition. The new Helper methods mark a function so failure reporting skips it when choosing a file and line. A reusable assertion helper can then report the location of the call that failed, which is usually where a test author needs to inspect the input or expectation.
I consider those library details part of the value of a beta. Programs depend on diagnostics and explicit runtime controls as well as the main execution path. The tagged notes make it possible to inspect these changes as they exist today, including incomplete documentation, while the release commit records a concrete failure discovered by exercising the build process itself.