A first release candidate for v1.12 of the Go programming language is now available for final pre-release testing.
The release comes without any changes to the actual language specification, but improvements to the toolchain, runtime, and libraries. For example in the compiler toolchain there are now more functions eligible for inlining by default and the compiler accepts a flag setting the language version to use.
Stack frame pointers on Linux/ARM64 are maintained so that profiling tools like perf have more to work with. Those not interested in this sort of thing should consider setting GOEXPERIMENT to noframepointer when running make.bash to build their toolchain, since the pointer also introduces a small overhead.
A helpful addition to the trace tool is the now included plotting function for mutator utilisation, which can be used to learn more about the garbage collector’s impact. Improvements to argument printing and variable location information in the DWARF debug information should support any bug hunting endeavours.
Once updated, the Go runtime will amongst other things provide less allocation latency after garbage collection, offer more accurate memory profiles and free memory for the operating system faster. Changes in the core libraries are mainly confined to cryptography, since v1.12 will be the first version with optional support of TLS 1.3.
Go was initially developed at Google and is known as a central building block of the container ecosystem. Docker, Kubernetes, and Prometheus are just a few prominent examples of projects implemented in the language. It can also be found in infrastructural components at companies such as Netflix, Dropbox and Twitch, often replacing Python.
Version 1.12 is not only the last version to be supported on FreeBSD 10.x, but also the last to not follow the proposal evaluation process introduced in late 2018 to account for the large number of high-profile projects using Go.
To not split the ecosystem and keep the language moving, the Go team will, starting with v1.13, identify a small number of language proposals, announce those, and collect feedback.
Afterwards the changes will be implemented, giving users another chance to voice concerns in the process. Ahead of the repository freeze that goes along with a release, the team will decide if the changes make for a valuable addition and either ship or rework/discard them. Slight adjustments to the process are still likely, since it is in an early testing stage.