presentation.slide

Go 1.9 Release Party
Sydney Go Users' Group
17 Aug 2017

Dave Cheney
@davecheney

* License and Materials

This presentation is licensed under the [[https://creativecommons.org/licenses/by-sa/4.0/][Creative Commons Attribution-ShareAlike 4.0 International]] licence.

The materials for this presentation are available on GitHub:

.link https://github.com/davecheney/go-1.9-release-party

You are encouraged to remix, transform, or build upon the material, providing you distribute your contributions under the same license.

If you have suggestions or corrections to this presentation, please raise [[https://github.com/davecheney/go-1.9-release-party/issues][an issue on the GitHub project]].

* Go 1.9

Go 1.9 isn't released, yet. 🙁

But, it is _very_ close, so for all intents and purposes, Go 1.9 is here!

# TODO .link https://t.co/cIEsMPeY0k Go 1.9 Announcement 

Go 1.9 is the 10th release in the Go 1 series. It follows from the previous version, Go 1.8, [[https://blog.golang.org/go1.8][released on the 16th of February, 2017]]

.link http://beta.golang.org/doc/go1.9 Draft Go 1.9 Release Notes
.link https://github.com/golang/go/issues/21297 The last minute blocker

* What's happened in the last six months?

What's changed?

- Language changes
- Ports
- Performance
- Toolchain changes
- Changes to the standard library

* Language changes

* Type Aliases

Go now supports type aliases to support gradual code repair while moving a type between packages.

In short, a type alias declaration has the form:

 type T1 = T2

This declaration introduces an alias name T1—an alternate spelling—for the type denoted by T2; that is, both T1 and T2 denote the same type.

The type alias design document and an article on re-factoring cover the problem in detail.

.link https://golang.org/design/18130-type-alias Type aliases design document.
.link https://talks.golang.org/2016/refactor.article Code base Re-factoring (with help from Go).

#* Type Aliases (example)
#
#
#.play -edit examples/type-aliases.go

* Ports

No new ports were added during 1.9, however there have been some changes to the support platforms.

- ppc64 Big and Little Endian require Power8 hardware. Unless you're running Go on a PowerMac G5, this doesn't affect you.
- Go 1.9 is the last release to support FreeBSD 9.3. Go 1.10 will require FreeBSD 10.3 or later.
- Go 1.9 requires OpenBSD 6.0 or later. OpenBSD 5.9 is no longer supported (but it's not supported by the OpenBSD project either, ᕕ( ᐛ )ᕗ).

* Performance

* Performance

As always, the changes are so general and varied that precise statements about performance are difficult to make.

Most programs should run a bit faster, due to speedups in the garbage collector and optimizations in the standard library.

Do you have a Go 1.9 performance story to tell? Blog it, and I'll retweet the crap out of it.

* Garbage collector specific 

- Library functions that used to trigger stop-the-world garbage collection now trigger concurrent garbage collection. Specifically, `runtime.GC`, `debug.SetGCPercent`, and `debug.FreeOSMemory`, now trigger concurrent garbage collection, blocking only the calling goroutine until the garbage collection is done.
- The `debug.SetGCPercent` function only triggers a garbage collection if one is immediately necessary because of the new `GOGC` value. This makes it possible to adjust `GOGC` on-the-fly.
- Large object allocation performance is significantly improved in applications using large (>50GB) heaps containing many large objects.
- In Go 1.8 the cost of calling `runtime.MemStats` is proportional to the size of the heap; Austin recently timed it at ~1.7ms per Gb. In Go 1.9 the function now takes less than 100µs even for very large heaps.

.link https://golang.org/issue/13613

* Toolchain improvements

* Parallel Compilation

The `go` tool has always compiled `runtime.NumCPUs()` packages in parallel.

With Go 1.9, inside a single package functions are now compiled in parallel.

Depending on the width and height of your dependency tree, and the number of cores available, this could give no speed up, or a measurable improvement.

 export GO19CONCURRENTCOMPILATION=0

disables this behaviour.

* ./... no longer matches vendor/...

No more

 go test $(go list ./... | grep -v vendor)

shenanigans. 

If you _do_ want to test your code under `vendor/`, you can use something like

 go test ./vendor/...

.link https://github.com/golang/go/issues/19090
.link https://tip.golang.org/doc/go1.9#vendor-dotdotdot

* Default $GOROOT

The go tool will now use the path from which it was invoked to attempt to locate the root of the Go install tree.

This means that if the entire Go installation is moved to a new location, the go tool should continue to work as usual.

This is one less reason to need to explicitly set `$GOROOT`.

_Note:_ this does not affect the result of the `runtime.GOROOT` function, which will continue to report the original installation location; this may be fixed in later releases.

* go env -json

The new `go`env`-json` flag enables JSON output, instead of the default OS-specific output format.

 % go env -json 
 {
        "CC": "gcc",
        "CGO_CFLAGS": "-g -O2",
        "CGO_CPPFLAGS": "",
        "CGO_CXXFLAGS": "-g -O2",
        "CGO_ENABLED": "1",
        "CGO_FFLAGS": "-g -O2",
        "CGO_LDFLAGS": "-g -O2",
        "CXX": "g++",
        "GCCGO": "gccgo",
        "GOARCH": "amd64",
        "GOGCCFLAGS": "-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build254210362=/tmp/go-build -gno-record-gcc-switches",
        "GOHOSTARCH": "amd64",
        "GOHOSTOS": "linux",
        "GOOS": "linux",
        "GOPATH": "/home/dfc",
        "GOROOT": "/home/dfc/go",
        "GOTOOLDIR": "/home/dfc/go/pkg/tool/linux_amd64"
 } 

* go test -list 

The go test command accepts a new `-list` flag, which takes a regular expression as an argument and prints to stdout the name of any tests, benchmarks, or examples that match it, without running them.

 % go test -list Compare bytes
 TestCompare
 TestCompareIdenticalSlice
 TestCompareBytes
 BenchmarkBytesCompare
 BenchmarkCompareBytesEqual
 BenchmarkCompareBytesToNil
 BenchmarkCompareBytesEmpty
 BenchmarkCompareBytesIdentical
 BenchmarkCompareBytesSameLength
 BenchmarkCompareBytesDifferentLength
 BenchmarkCompareBytesBigUnaligned
 BenchmarkCompareBytesBig
 BenchmarkCompareBytesBigIdentical

* go tool pprof

pprof has received some love.

Profiles produced by the runtime/pprof package now include symbol information, so they can be viewed in go tool pprof without the binary that produced the profile.

 % go test -test.run=xxx -test.bench=Max strings -test.cpuprofile=c.p
 BenchmarkSingleMaxSkipping-4     2000000               912 ns/op        10964.09 MB/s
 PASS
 ok      strings 3.054s
 % go tool pprof c.p

The `go`tool`pprof` command now uses the HTTP proxy information defined in the environment, using `http.ProxyFromEnvironment`.

.link https://rakyll.org/profiler-labels/ Profiler labels in Go

* Other toolchain improvements

- Complex division is now C99-compatible. This has always been the case in gccgo and is now fixed in the gc toolchain.
- The linker will now generate DWARF information for cgo executables on Windows.
- The compiler now includes lexical scopes in the generated DWARF if the `-N`-l` flags are provided, allowing debuggers to hide variables that are not in scope. The `.debug_info` section is now DWARF version 4.
- The values of `GOARM` and `GO386` now affect a compiled package's build ID, as used by the go tool's dependency caching.

* Runtime changes

* Mid-stack inlining

Inlining has historically been limited to leaf functions because of the concern of aggressive inlining on stack trace output.

Users of `runtime.Callers` should avoid directly inspecting the resulting PC slice and instead use `runtime.CallersFrames` to get a complete view of the call stack, or `runtime.Caller` to get information about a single caller. This is because an individual element of the PC slice cannot account for inlined frames or other nuances of the call stack.

Specifically, code that directly iterates over the PC slice and uses functions such as `runtime.FuncForPC` to resolve each PC individually will miss inlined frames. To get a complete view of the stack, such code should instead use `CallersFrames`.

Code that queries a single caller at a specific depth should use `Caller` rather than passing a slice of length 1 to `Callers`.

`runtime.CallersFrames` has been available since Go 1.7, so code can be updated prior to upgrading to Go 1.9.

.link https://github.com/golang/go/issues/17566 Issue 17566

* runtime poller improvements

Go has used epoll/kqueue/poll/select for _network_sockets_ for years.

Reads/Writes to other file descriptors have traditionally consumed a thread during operation.

Ian Lance Taylor landed a refactor that broke out the `runtime` polling subsystem and extended to work for the rest of the `os` package.

The `os` package now uses the internal runtime poller for file I/O. This reduces the number of threads required for read/write operations on pipes, and it eliminates races when one goroutine closes a file while another is using the file for I/O.
 
* Plugins

Not much has changed, still lots to do.

David Crawshaw gave a great talk about all the ways that Go code can be built to interact with other languages, and itself (plugins) at GopherCon this year.

.link https://www.youtube.com/watch?v=x-LhC-J2Vbk David Crawshaw - Go Build Modes (GopherCon 2017)

# * Tool changes

# * go tool trace

* Go one-line installer

Jess Frazelle and Chris Broadfoot have been working on a one line binary installer for Go.

.link https://groups.google.com/forum/#!searchin/golang-dev/getgo%7Csort:relevance/golang-dev/QrchAUETfUI/pOOZFx-GAgAJ Go one-line installer

The installer is designed to both install Go as well as do the initial configuration of setting up the right environment variables and paths.

Personally, I'm a little disapointed they didn't name it _upgoer_.

* Changes to the standard library

* Transparent Monotonic Time support

The time package now transparently tracks monotonic time in each `Time` value, making computing durations between two `Time` values a safe operation in the presence of wall clock adjustments.

If a `Time` value has a monotonic clock reading, its string representation (as returned by `String`) now includes a final field "m=±value", where value is the monotonic clock reading formatted as a decimal number of seconds.

The new methods Duration.Round and Duration.Truncate handle rounding and truncating durations to multiples of a given duration.

.link https://tip.golang.org/pkg/time/#hdr-Monotonic_Clocks
.link https://golang.org/design/12914-monotonic

* time.String (cont.)

.play -edit examples/time-string.go

Just as you shouldn't compare `t1`==`t2` because they may be in a different timezone, you shouldn't also compare `t1.String()`==`t2.String()`.

- To compare times, use `time.Equal()`
- When serialising `time.Time` values `time.MarshalBinary`, `time.MarshalJSON`, and `time.MarshalText` elide the monotonic component.

.link https://www.youtube.com/watch?v=OuT8YYAOOVI Joe Tsai, Forward Compatible Go Code (GopherCon 2017)

* sync.Map

The `sync` package has a new type, `sync.Map`

`sync.Map` is a concurrent map with amortized-constant-time loads, stores, and deletes. It is safe for multiple goroutines to call a Map's methods concurrently.

`sync.Map` is _not_ a general purpose replacement for a `sync.Mutex`/`RWMutex` and the built in `map` type.

.link https://github.com/golang/go/issues/18177
.link https://www.youtube.com/watch?v=C1EtfDnsdDs Lightning Talk: Bryan C Mills - An overview of sync.Map (GopherCon 2017)
.link https://github.com/gophercon/2017-talks/blob/master/lightningtalks/BryanCMills-AnOverviewOfSyncMap/An%20Overview%20of%20sync.Map.pdf Lightning Talk: Bryan C Mills - An overview of sync.Map (Slides)

* math/bits

As an experiment in addressing the needs of low level crypto and bit twiddling needs of package writers, Go 1.9 includes a new package, `math/bits`.

`math/bits` contains functions to operate on values representing bit shifts, rotates, masks, and counts.

Where implemented by SSA backends, the `math/bits` functions are replaced by a native sequence of instructions. When no specific instruction exists, or is not implemented, the compiler treats the `math/bits` package as normal Go code.

.link https://tip.golang.org/pkg/math/bits/ math/bits

.play -edit examples/math-bits.go /START/,/END/

* testing.Helper()

The new `(*T).Helper` and `(*B).Helper` methods mark the calling function as a test helper function. When printing file and line information, that function will be skipped. This permits writing test helper functions while still having useful line numbers for users.

Use it to exclude testing helpers from `t.Errorf()` and `t.Fatalf()` tracebacks.

.play -edit examples/testing-helper.go /START/,/END/ 

* And much more ...

- `crypto/rand` - On Linux, Go now calls the getrandom system call without the `GRND_NONBLOCK` flag; it will now block until the kernel has sufficient randomness. 
- `crypto/x509` - On Unix systems the environment variables `SSL_CERT_FILE` and `SSL_CERT_DIR` can now be used to override the system default locations for the SSL certificate file and SSL certificate files directory, respectively.
- `os/exec` - The `os/exec` package now de-duplicates environment variables in the `exec.Cmd.Env` slice.
- `os/user` - `Lookup` and `LookupId` now work on Unix systems when `CGO_ENABLED=0` by reading the `/etc/passwd` file.
- `text/template` - The handling of empty blocks, which was broken by a Go 1.8 change that made the result dependent on the order of templates, has been fixed.

.link https://tip.golang.org/doc/go1.9#minor_library_changes

* dep

The official experiment.

.link https://github.com/golang/dep

Try it, use it, start making releases, start tagging your releases.

.link https://www.youtube.com/watch?v=5LtMb090AZI Sam Boyer, GopherCon 2017
.link https://dave.cheney.net/2016/06/24/gophers-please-tag-your-releases

* Go 1.next

The next release of Go will be ... wait for it ... Go 1.10.

* Go.future

A GopherCon in July Russ Cox 

.link https://blog.golang.org/toward-go2 Towards Go 2 (blog.golang.org)
.link https://www.youtube.com/watch?v=0Zbh_vmAKvk Russ Cox, The Future of Go (GopherCon 2017)

"The conversation for Go 2 starts today, and it's one that will happen in the open, in public forums like the mailing list and the issue tracker. Please help us at every step along the way.

"Today, what we need most is experience reports. Please tell us how Go is working for you, and more importantly not working for you. Write a blog post, include real examples, concrete detail, and real experience. And link it on our wiki page. That's how we'll start talking about what we, the Go community, might want to change about Go.
.caption Russ Cox

.link https://github.com/golang/go/wiki/ExperienceReports Experience Reports (Go wiki)

# experience reports
# random proposals don't count, you have to explain what the problem is _before_ you start talking about what you want to change.

* Conclusion

.image img/party-gopher.png
.caption image credit Renee French

Upgrade to Go 1.9, now!

I know I said this last time, but it's still true that Go 1.9 (will be) literally the best version of Go so far.