Two more months until Go: 1.16 beta offers improved tooling up for a test-drive

Two more months until Go: 1.16 beta offers improved tooling up for a test-drive

With two more months until the final Go 1.16 release, the Go team has called upon developers to start testing the newly cut first beta version of the programming language. However, those looking to play with new language features might have to sit this one out, as work has mainly been done on the tooling and infrastructure front this time around.  

Most changes can be found in the go command which now allows the embedding of static files and file trees into executables through a new //go:embed directive, and has become module-aware by default. To support the latter, go install has learned to accept arguments with version suffixes for installing packages in module mode without taking the go.mod file into account. 

Using the install command has also become the recommended approach to building and installing packages in that mode, which means go get (plus the -d flag) is only meant to be used to adjust a module’s dependencies from now on. 

Should a certain version of a model be unsuitable for general consumption, developers can indicate that by using retract directives in their go.mod file. The latter by the way isn’t modified by default when using build commands anymore; instead go throws an error if requirements or checksums are causing trouble.

Teams using older version control tools should take a look at the newly introduced GOVCS environment variable, which looks to mitigate security issues by limiting which version control tool the go command may use for downloading source code. Some manual work might also be necessary for those using the go get -insecure flag or the -i flag in their scripts, since both have been deprecated in Go 1.16.

Other notable tooling enhancements include a change in behaviour of C calling tool cgo, which no longer translates C struct bitfields into Go struct fields, and a new warning about invalid testing.T use in goroutines in Go’s code examination helper vet.

Leading up to the release, the Go team continued its linker modernisation initiative, which apparently leaves the component less resource hungry and easier to maintain. The Go compiler also received some attention and is now able to inline functions with for loops, method values, and type switches that aren’t labeled.

Users interested in having a look at implementation-defined metrics from the Go runtime and who feel like runtime.ReadMemStats and debug.GCStats are a bit too specific should take a look at the new runtime/metrics package. 

Other interesting improvements in the runtime come in the form of a fix that should keep the race detector better in sync with the Go memory model to identify more issues, as well as a way to trace each package’s execution time and memory allocation.

In terms of ports, Go 1.16 adds support for 64-bit arm architecture on macOS and NetBSD, while the RISC-V version has learned to work with cgo and -buildmode=pie and MIPS64 support has landed in the OpenBSD flavour.

Currently the final release of Go 1.16 is planned for February 2021. Those wondering what else to expect from the new version can take a look at the draft release notes.

Feature development for Go has slowed down a bit in recent years, which is mainly due to the introduction of a proposal evaluation process in November 2018. Back then, language co-designer Robert Griesemer explained the new approach with the constraints put onto his team by the “millions of Go programmers and a large body of Go code”. 

To keep them all onboard and to keep the impact on systems relying on Go (think container tech) minimal, the team now selects a small number of proposals that address the most important issues for each release, collects feedback, and comes up with an implementation which serves as the basis for further discussions.