Go 1.7 Release Party in Tokyo GoCon Tokyo 8 August 2016 Taichi Nakashima

About me @deeeet / @tcnksm (GitHub)

/ (GitHub) http://deeeet.com

A PaaS Dev&Ops (Using CloudFoundry) 2

OSS Tools gcli - The easy way to build Golang command-line application

gotests - A tool to generate Go test functions from the given source code like gofmt

ghr - Create Github Release and upload artifacts in parallel

license - Generate LICENSE file you want

kafka-firehose-nozzle - Integrate CloudFoundry with Apache Kafka Packages go-input - Go package for ideal tty prompt

go-latest - Simple way to check version is latest or not from various sources in Go

go-nozzle - Go package for building CloudFoundry nozzle 3

Welcome Let's celebrate the release of Go1.7. 4

Welcome Not yet released (8 Aug) ... 5

Go 1.7 The latest Go release, version 1.7, arrives six months after 1.6 (17 February). Most of its changes are in the implementation of the toolchain, runtime, and libraries. There are no changes to the language specification. As always, the release maintains the Go 1 compatibility guarantee. Almost all Go programs are expected to continue to compile and run as before. 7

New ports macOS 10.12 Sierra (This support was backported to Go 1.6.3. Binaries built with versions of Go before 1.6.3 will not work correctly on Sierra) Experimental port to Linux on z Systems (linux/s390x) The beginning of a port to Plan 9 on ARM (plan9/arm) 8

Tools 9

Tools Compiler Toolchain

Go command

Go vet 10

Compiler Toolchain (SSA) This release includes a new code generation back end for 64-bit x86 systems. The new back end, based on SSA, generates more compact, more efficient code and provides a better platform for optimizations such as bounds check elimination. The new back end reduces the CPU time required by official benchmark programs by 5-35%. For this release, the new back end can be disabled by passing -ssa=0 to the compiler. 11

Compiler Toolchain (New export) The format of exported metadata written by the compiler in package archives has changed: the old textual format has been replaced by a more compact binary format. This results in somewhat smaller package archives and fixes a few long-standing corner case bugs. For this release, the new export format can be disabled by passing -newexport=0 to the compiler. 12

Compiler Toolchain (Linker) The compiler and linker have been optimized and run significantly faster in this release than in Go 1.6, although they are still slower than we would like and will continue to be optimized in future releases. 13

Compiler Toolchain (Compilation time improvements) Because of translation from C to Go in Go1.5, compile times are slower than they used to be... around 3x slower than 1.4.3. Go 1.7 toolchain improvements Now the slowdown is 2.2x than 1.4.3 🎉 14

Compiler Toolchain (Linker time improvements) Go 1.7 toolchain improvements > 10% faster for any non trivial binary, and up to 30% faster for large binaries like jujud. 15

Compiler Toolchain (Stack frame) On x86-64 systems, Go programs now maintain stack frame pointers as expected by profiling tools like Linux's perf and Intel's VTune, making it easier to analyze and optimize Go programs using these tools. The frame pointer maintenance has a small run-time overhead that varies but averages around 2%. We hope to reduce this cost in future releases. To build a toolchain that does not use frame pointers, set GOEXPERIMENT=noframepointer when running make.bash, make.bat, or make.rc. 16

Compiler Toolchain (-X option) The linker's -X option no longer supports the unusual two-argument form -X name value, as announced in the Go 1.6 release and in warnings printed by the linker, $ go build -ldflags="-X main.Commit $GIT_COMMIT" Use -X name=value instead, $ go build -ldflags="-X main.Commit=$GIT_COMMIT" 18

Go command The go command's basic operation is unchanged, but there are a number of changes worth noting. Removes support for the GO15VENDOREXPERIMENT environment variable

environment variable "go list" now includes a StaleReason field explaining why a particular package is or is not considered stale

Supports import paths referring to git.openstack.org 19

Go command (Binary-only package) This release adds experimental, minimal support for building programs using binary-only packages, packages distributed in binary form without the corresponding source code. The minimal source code for a binary-only package, //go:binary-only-package package hello Full example is on tcnksm/go-binary-only-package 20

Go Vet (-tests) Adds a new -tests check that checks the name and signature of likely test functions. func TestbadSuffix(*testing.T) {} // ERROR "first letter after 'Test' must not be lowercase" 21

Go Vet (-lostcancel) Add a new -lostcancel that checks which detects failure to call the cancelation function returned by the WithCancel , WithTimeout , and WithDeadline functions in Go 1.7's new context package. func _() { ctx, cancel := context.WithCancel() defer cancel() // ok } func _() { ctx, cancel := context.WithCancel() // ERROR "the cancel function is not used on all paths \(possible context leak\)" } // ERROR "this return statement may be reached without using the cancel var defined on line 17" 22

Performance 23

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 core library. On x86-64 systems, many programs will run significantly faster, due to improvements in generated code brought by the new compiler back end. The code generation changes alone typically reduce program CPU time by 5-35%. There have been significant optimizations bringing more than 10% improvements to implementations in the crypto/sha1, crypto/sha256, encoding/binary, fmt, hash/adler32, hash/crc32, hash/crc64, image/color, math/big, strconv, strings, unicode, and unicode/utf16 packages. 24

Performance (GC) Garbage collection pauses should be significantly shorter than they were in Go 1.6 for programs with large numbers of idle goroutines, substantial stack size fluctuation, or large package-level variables. Go's march to low-latency GC 25

Standard library 26

Standard library Context

Testing

HTTP Tracing 27

Context Go 1.7 moves the golang.org/x/net/context package into the standard library as context . This allows the use of contexts for cancelation, timeouts, and passing request-scoped data in other standard library packages, including net, net/http, and os/exec New interface (contract) for passing cancellation signal and scoped values (like request token). Go Concurrency Patterns: Context

Context by Peter Bourgon (about context.Value ) 28

Context (net/http) As a http client, you can pass Context by Request.WithContext() method. ctx, cancel := context.WithTimeout(context.Background(), 100*time.Millisecond) defer cancel() req, err := http.NewRequest("GET", "https://google.com", nil) if err != nil { log.Fatal(err) } req = req.WithContext(ctx) client := http.DefaultClient res, _ := client.Do(req) As a http handler, you can get the given Context by Request.Context() method. func handler(w http.ResponseWriter, r *http.Request) { ctx := r.Context() // ... } 29

Context (os/exec) You can create context-powered exec.Cmd cmd := exec.CommandContext(ctx, "awesome_command") if err := cmd.Run(); err != nil { log.Fatal(err) } The provided context is used to kill the process (by calling os.Process.Kill ) if the context becomes done before the command completes on its own. 30

Testing The testing package now supports the definition of tests with subtests and benchmarks with sub-benchmarks. This support makes it easy to write table-driven benchmarks and to create hierarchical tests. It also provides a way to share common setup and tear-down code. Go1.7のSubtestsとSub-benchmarks 31

Testing (before) When you want to take benchmark of method Foo with different configuration, func BenchmarkFoo1(b *testing.B) { benchFoo(b, 1) } func BenchmarkFoo10(b *testing.B) { benchFoo(b, 10) } func BenchmarkFoo100(b *testing.B) { benchFoo(b, 100) } func benchFoo(b *testing.B, base int) { for i := 0; i < b.N; i++ { Foo(base) } } You need to define functions for each configuration 32

Testing (after) When you want to take benchmark of method Foo with different configuration, func BenchmarkFoo(b *testing.B) { cases := []struct { Base int }{ {Base: 1}, {Base: 10}, {Base: 100}, } for _, bc := range cases { b.Run(fmt.Sprintf("%d", bc.Base), func(b *testing.B) { benchFoo(b, bc.Base) }) } } You can use table-driven approach for benchmark. 33

HTTP Tracing Go 1.7 introduces net/http/httptrace , a package that provides mechanisms for tracing events within HTTP requests. You can set the following hooks to run at various stages of an HTTP client request. type ClientTrace struct { // GetConn is called before a connection is created. GetConn func(hostPort string) // GotConn is called after a successful connection is obtained. GotConn func(GotConnInfo) // WroteHeaders is called after the Transport has written // the request headers. WroteHeaders func() // WroteRequest is called with the result of writing the // request and any body. WroteRequest func(WroteRequestInfo) // And more } 34

HTTP Tracing You can pass httptrace hooks via Context package main import ( "context" "log" "net/http" "net/http/httptrace" ) func main() { req, err := http.NewRequest("GET", "https://google.com", nil) if err != nil { log.Fatal(err) } // Set hooks trace := httptrace.ClientTrace{ GetConn: func(h string) { log.Println("GetConn:", h) }, } ctx := httptrace.WithClientTrace(context.Background(), &trace) req = req.WithContext(ctx) client := http.DefaultClient res, _ := client.Do(req) _ = res } 35

Standard library And a lot of minor changes 👍 36