go1.6.slide

Go 1.6 release party
YOUR MEETUP
17 Feb 2016

YOUR NAME
@YOURTWITTER
http://talks.godoc.org/github.com/davecheney/gosyd/go1.6.slide

* DEMONSTRATIONS

THE CODE SAMPLES IN THIS SLIDE DECK REQUIRE GO 1.6

THEY WILL NOT WORK FROM TALKS.GOLANG.ORG UNTIL AFTER GO 1.6 IS RELEASED

TO RUN THEM LOCALLY YOU WILL NEED GO 1.6BETA1 OR LATER

* Welcome

Today (Feb 17th) is an attempt at a release party for Go 1.6 involving as many Go user groups as possible.

There are 50 Go user groups taking part, you can find [[https://github.com/golang/go/wiki/Go-1.6-release-party#whos-involved][a list of them here]].

This presentation is based _heavily_ on the [[http://tip.golang.org/doc/go1.6][official Go 1.6 release notes]].

This presentation contains lots of links to further reading. You can find it online, [[http://talks.godoc.org/github.com/davecheney/gosyd/go1.6.slide][talks.godoc.org/github.com/davecheney/gosyd/go1.6.slide]]

* Artwork

.image go1.6/Go_release_party_1.6_wide.png 500 _

_Credit_: [[https://groups.google.com/d/msg/go-meetup-organisers/5FFI9Azo2TE/_lyJU_xMEgAJ][Frédéric Menez / Golang Paris meetup]].

* Go 1.6

The latest Go release, version 1.6, arrives six months after 1.5.

Most of its changes are in the implementation of the language, runtime, and libraries. There are no changes to the language specification.

As always, the release maintains the [[http://tip.golang.org/doc/go1compat.html][Go 1 compatibility guarantee]].

Almost all Go programs are expected to continue to compile and run as before.

* The Go project by the numbers

Go was announced as an open source project November 10th, 2009.

Releases occur on a ~6 month cadence with several bug fix point releases between each major release.

Release timeline:

- [[http://blog.golang.org/the-path-to-go-1][Go 1.0]] released 28th March, 2012
- [[http://talks.golang.org/2013/go1.1.slide#1][Go 1.1]] released 13th May, 2013
- Go 1.2 released 1st December, 2013
- Go 1.3 released 18th June, 2014
- Go 1.4 released 10th December, 2014
- [[https://talks.golang.org/2015/state-of-go.slide#8][Go 1.5]] released 19th August, 2015
- Go 1.6 is expected to be released February, 2016

* Supported platforms

Go 1.6 supports the following operating systems:

- Windows, OSX (darwin), Android, iOS, NaCl, DragonflyBSD, FreeBSD, Linux, NetBSD, OpenBSD, Plan 9, Solaris/Illumos

Go 1.6 supports the following CPU architectures:

- Intel (386 and amd64), arm (ARMv5, v6, v7), arm64, 64 bit PowerPC (big and little endian), 64 bit MIPS (big and little endian)

In the future:

- s390x (IBM Z series) planned for Go 1.7
- RISC-V may be on the horizon

* Cross compilation

As of Go 1.5, you no longer need to 'bless' your Go install before cross compiling—it just works*.

    # cross compile from your machine to Windows
    env GOOS=windows go build $YOURPACKAGE

This works with the binary release from the [[https://golang.org/dl/][golang.org]].

Read more:

- [[http://dave.cheney.net/2015/08/22/cross-compilation-with-go-1-5][Cross compilation with Go 1.5]]
- [[https://medium.com/@rakyll/go-1-5-cross-compilation-488092ba44ec#.7wrgy0a5s][Go 1.5: Cross compilation]]

_*_Unless_your_code_uses_cgo_

* Garbage collector improvements

Go 1.5 introduced a low latency garbage collector.

The new collector trades throughput for reduced latency.

Allocations pay (in terms of time) a little up front to reduce the time taken to clean up later, this reduces the overall time the gc has to stop the world.

For Go 1.6, a lot of work went into optimising and tuning the gc, enabling far larger heaps to be managed within the 10ms latency goal.

* Go 1.5

At [[https://www.youtube.com/watch?v=aiv1JOfMjm0][GopherCon 2015 Rick Hudson gave a presentation]] about the Go 1.5 low latency collector

.image go1.6/go15.png 400 _

* Go 1.6

At [[http://www.infoq.com/presentations/go-gc-performance][QCon SF in November Rick Hudson]] gave an updated presentation which showed this comparison of Go 1.5 to the upcoming Go 1.6

.image go1.6/go16.png 400 _

_Yes,_that_is_gigabytes_on_the_X_axis_

* HTTP/2

Go 1.6 adds transparent support in the `net/http` package for the new HTTP/2 protocol.

Go clients and servers will automatically use HTTP/2 as appropriate when using HTTPS.

Programs that must disable HTTP/2 can do so by setting `Transport.TLSNextProto` (for clients) or `Server.TLSNextProto` (for servers) to a non-nil, empty map.

Read more

- [[https://http2.golang.org/][HTTP/2 demo site]] (powered by Go)
- [[https://www.youtube.com/watch?v=gukAZO1fqZQ][Here is a video of Brad Fitzpatrick giving an overview of Go 1.6's HTTP/2 support]] at the London Go Gathering in 2015.

* Sharing pointers between Go and C

The major change to cgo in Go 1.6 is the rules for sharing Go pointers with C code, to ensure that such C code can coexist with Go's garbage collector, have been clarified.

Go and C may share memory allocated by Go when:

- a pointer to that memory is passed to C as part of a cgo call,
- and provided that the memory itself contains no pointers to Go-allocated memory,
- and provided that C does not retain the pointer after the call returns.

These rules are checked by the runtime during program execution: if the runtime detects a violation, it prints a diagnosis and crashes the program.

The checks can be disabled by setting the environment variable `GODEBUG=cgocheck=0`, but note that disabling the checks will typically only lead to more mysterious failure modes.

Fixing the code in question should be strongly preferred over turning off the checks.

* Sharing pointers between Go and C (cont.)

.play go1.6/cgo.go

* Compiler Toolchain

Externally the compiler toolchain is mostly unchanged compared to Go 1.5.

Internally, the most significant change is that the parser is now hand-written instead of generated from yacc.

The new SSA compiler backend is slated to land, for amd64 only at this stage, in Go 1.7.

* Changes to the -X flag

In Go 1.5 the linker's -X flag changed.

In Go 1.4 and earlier, it took two arguments, as in

    -X importpath.name value

Go 1.5 added an alternative syntax using a single argument that is itself a name=value pair:

    -X importpath.name=value

In Go 1.5 the old syntax was still accepted, after printing a warning suggesting use of the new syntax instead. Go 1.6 continues to accept the old syntax and print the warning. Go 1.7 will remove support for the old syntax.

* maps throw if you misuse them

The runtime has added lightweight, best-effort detection of concurrent misuse of maps.

If the runtime detects this condition, it prints a diagnosis and crashes the program.

    fatal error: concurrent map writes

    goroutine 2726 [running]:
    runtime.throw(0x192d630, 0x15)
        /usr/lib/go/src/runtime/panic.go:530 +0x90 fp=0xc8202eb838 sp=0xc8202eb820

The best way to find out more about the problem is to run the program under the race detector.

* maps throw if you misuse them (example)

.play go1.6/map.go /START OMIT/,/END OMIT/

* Panic messages are shorter by default

For program-ending panics, the runtime now by default prints _only_the_stack_of_the_running_goroutine_, not all existing goroutines.

Usually only the current goroutine is relevant to a panic, so omitting the others significantly reduces irrelevant output in a crash message.

To see the stacks from all goroutines in crash messages, set the environment variable `GOTRACEBACK` to all or call `debug.SetTraceback` before the crash, and rerun the program.

    env GOTRACEBACK=all ./crashy

Read more:

- [[http://dave.cheney.net/2015/11/29/a-whirlwind-tour-of-gos-runtime-environment-variables#GOTRACEBACK][A whirlwind tour of Go’s runtime environment variables]]

* Panic messages are shorter by default (example)

.play go1.6/crashy.go /START OMIT/,/END OMIT/

* Windows timer resolution

On Windows, Go programs in Go 1.5 and earlier forced the global Windows timer resolution to 1ms at startup by calling `timeBeginPeriod(1)`.

This makes Windows users' batteries sad.

Go 1.6 no longer needs this for good scheduler performance, and changing the global timer resolution caused problems on some systems, so the call has been removed.

* Vendor support

Go 1.5 introduced experimental support for vendoring, enabled by setting the `GO15VENDOREXPERIMENT` environment variable to 1

Go 1.6 keeps the vendoring support, no longer considered experimental, and enables it by default.

It can be disabled explicitly by setting the GO15VENDOREXPERIMENT environment variable to 0. Go 1.7 will remove support for the environment variable.

The most likely problem caused by enabling vendoring by default happens in source trees containing an existing directory named `vendor` that does not expect to be interpreted according to new vendoring semantics. In this case, the simplest fix is to rename the directory to anything other than vendor and update any affected import paths.

* How does it work?

        /home/user/gocode/
            src/
                server-one/
                    main.go            (import "github.com/gorilla/mux")
                server-two/
                    main.go            (import "github.com/gorilla/mux")
                    vendor/
                        github.com/
                            gorilla/
                                mux/
                                    ...

`server-one` uses the `mux` package in

	$GOPATH/src/github.com/gorilla/mux

`server-two` uses the `mux` package in

	$GOPATH/src/server-two/vendor/github.com/gorilla/mux

* Vendoring (demo)

* Vendoring gotchas

Vendored code matches ./...

If you're used to doing

   % cd $GOPATH/github.com/you/repo
   % go test ./...

The go tool glob operator `...`, _also_matches_ things in your `vendor/` directory.

The workaround is to filter out vendored packages by name

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

Read More

- [[https://github.com/golang/go/issues/11659#issuecomment-171678025][Issue 11659]]

* LLVM memory sanitizer, -msan

The compiler, linker, and go command have new flag `-msan`, analogous to `-race` that enables interoperation with the Clang MemorySanitizer.

Such interoperation useful mainly for testing a program containing suspect C or C++ code.

    go build -msan $YOURCOMMAND

This should probably be considered _experimental_ and only available on linux/amd64.

* Performance

On average the programs in the Go 1 benchmark suite run a few percent faster in Go 1.6 than they did in Go 1.5.

The garbage collector's pauses are even lower than in Go 1.5, although the effect is likely only noticeable for programs using a large amount of memory.

There have been significant optimizations bringing more than 10% improvements to implementations of the compress/bzip2, compress/gzip, crypto/aes, crypto/elliptic, crypto/ecdsa, and sort packages.

* Sorting

In the sort package, the implementation of `Sort` has been rewritten to make about 10% fewer calls to the Interface's `Less` and `Swap` methods.

The new algorithm does choose a different ordering than before for values that compare equal (those pairs for which `Less(i,`j)` and `Less(j,`i)` are false).

The definition of `Sort` makes no guarantee about the final order of _equal_values_, the new behavior may break programs that expect a specific order.

Such programs should either refine their Less implementations to report the desired order or should switch to `sort.Stable`, which preserves the original input order of equal values.

* sort.Sort example

.play go1.6/sort.go /START OMIT/,/END OMIT/

_Change_sort.Sort_to_sort.Stable_and_observe_the_effect_on_the_Bills_

* Stripping whitespace with text/template

It is now possible to trim spaces around template actions, which can make template definitions more readable.

A minus sign at the beginning of an action says to trim space before the action, and a minus sign at the end of an action says to trim space after the action.

.play go1.6/template.go

* Go vet command

The go vet command now diagnoses passing function or method values as arguments to Printf, such as when passing f where f() was intended.

.code go1.6/vet.go

    % go tool vet -all go1.6/vet.go
    go1.6/vet.go:6: arg r.UserAgent in printf call is a function value, not a function call

* Gccgo

The release schedules for the GCC and Go projects do not coincide.

GCC release 5 contains the Go 1.4 version of gccgo.

The next release, GCC 6, will have the Go 1.5 version of gccgo.

Due to release scheduling, it is likely that Go 1.6 will not be in a GCC release until GCC 7.

* Minor standard library changes

As well as the big improvements mentioned above, the standard library received many bug fixes and minor improvements.

This section highlights a few of these changes.

Read more

- [[https://tip.golang.org/doc/go1.6#minor_library_changes][Go 1.6 release notes]]

* archive/tar

Joe Tsai has put a lot of effort into the archive/tar package, correcting many bugs in rare corner cases of the file format.

One visible change is that the Reader type's Read method now presents the content of special file types as being empty, returning `io.EOF` immediately.

* bufio

The bufio package's Scanner type now has a Buffer method, to specify an initial buffer and maximum buffer size to use during scanning.

This makes it possible, when needed, to scan tokens larger than MaxScanTokenSize.

Also for the Scanner, the package now defines the ErrFinalToken error value, for use by split functions to abort processing or to return a final empty token.

* bufio (example)

.play go1.6/scan.go /START OMIT/,/END OMIT/

* net/* changes

The net/http package has a number of minor additions beyond the HTTP/2 support already discussed.

- The FileServer now sorts its generated directory listings by file name.
- The Client now allows user code to set the Expect: 100-continue header (see Transport.ExpectContinueTimeout).
- There are four new error codes from RFC 6585: StatusPreconditionRequired (428), StatusTooManyRequests (429), StatusRequestHeaderFieldsTooLarge (431), and StatusNetworkAuthenticationRequired (511).
- The implementation and documentation of CloseNotifier has been substantially changed. The Hijacker interface now works correctly on connections that have previously been used with CloseNotifier. The documentation now describes when CloseNotifier is expected to work.

* net/* changes (cont.)
- The net/http/httptest package's ResponseRecorder now initializes a default Content-Type header using the same content-sniffing algorithm as in http.Server.
- The net/url package's Parse is now stricter and more spec-compliant regarding the parsing of host names. For example, spaces in the host name are no longer accepted.
- net/url.Error type now implements `net.Error` to provide `Temporary` and `Timeout` behaviours.

* GODEBUG=netdns

The `net` package implements two DNS resolvers

- cgo based resolver which uses the platform's dns resolver
- the so called "pure Go" DNS resolver

The former is the default when not cross compiling, the latter is enabled exclusively when cross compiling.

For "native" builds, you can control this setting with

    export GODEBUG=netdns=go    # force pure Go resolver
    export GODEBUG=netdns=cgo   # force cgo resolver

Read more

- [[https://golang.org/pkg/net/#hdr-Name_Resolution][Name resolution section]] of the `net` package documentation.

* os

The os package's `IsExist`, `IsNotExist`, and `IsPermission` now return correct results when inquiring about a `SyscallError`.

On Unix-like systems, when a write to `os.Stdout` or `os.Stderr` fails due to a broken pipe error, the program will raise a `SIGPIPE` signal. By default this will cause the program to exit; this may be changed by calling the `os/signal.Notify` function for `syscall.SIGPIPE`. 

In Go 1.6 a write to a broken pipe on a file descriptor other 1 or 2 will simply return `syscall.EPIPE` (possibly wrapped in `os.PathError` and/or `os.SyscallError`) to the caller.

The old behavior of raising an uncatchable SIGPIPE signal after 10 consecutive writes to a broken pipe no longer occurs.

* regexp

In the regexp package, the Regexp type has always been safe for use by concurrent goroutines.

Some high-concurrency servers using the same Regexp from many goroutines have seen degraded performance due to contention on a mutex protecting a cache of scratch spaces used during regular expression searches.

To help such servers, Regexp now has a Copy method, which makes a copy of a Regexp that shares most of the structure of the original but has its own scratch space cache.

    re1 := regexp.MustCompile(`^(?P<root>github\.com/([A-Za-z0-9_.\-]+/[A-Za-z0-9_.\-]+))(/[A-Za-z0-9_.\-]+)*$`)
    re2 := re1.Copy()

A copy does have additional space overhead, so Copy should only be used when contention has been observed.

* time

The time package's Parse function has always rejected any day of month larger than 31, such as January 32.

In Go 1.6, Parse now also rejects February 29 in non-leap years, February 30, February 31, April 31, June 31, September 31, and November 31.

.play go1.6/parse.go

* Go 1.6

.link https://golang.org/dl/

.image go1.6/GoLaunch_Front.png 440 _

_Credit_: [[http://www.meetup.com/golangsf/events/226090306/][iron.io / GoSF Meetup]].