Go 1.8 Release Notes | Hacker News Reader

Go 1.8 Release Notes

beta.golang.org

389 pointspetercooper190 comments

OK, so now this is out, how about we discuss what is actually in this release!

The sort pkg now has a convenience for sorting slices, which will be a nice shortcut instead of having to define a special slice type just to sort on a given criteria, you can just pass a sorting function instead.

HTTP/2 Push is now in the server, which is fun, but like context might take a while for people to start using in earnest. Likewise graceful shutdown. Is anyone experimenting with this yet?

Plugins are here, but on Linux only for now - this will be interesting long term for things like server software which wants to let other compile plugins for it and distribute them separately, presently that has to be compiled in to the main binary.

Performance: GC times are now down to 10-100 microseconds, and defer and cgo are also faster. Compilation time improving but still not close to 1.4.

GOPATH is optional now, but you still do need a path where all go code is kept, perhaps eventually this requirement will go away - GOPATH/pkg is just a cache, GOPATH/bin is just an install location, and GOPATH/src could really be anywhere, so I'm not sure if long term a special go directory is required at all if vendoring takes off, then import paths could be project-local.

There's a slide deck here with a rundown of all the changes from Dave Cheney:

https://talks.godoc.org/github.com/davecheney/go-1.8-release...

Finally, as someone using Go for work and play, thanks to the Go team and everyone who contributed to this release. I really appreciate the incremental but significant changes in every release, and the stability of the core language.

> Compilation time improving but still not close to 1.4.

It's worth noting that this is mostly the result of an automatic translation from C to Go, which made the compiler slower, but also a lot more accessible to outside contributions.

And also, that in the meantime, the compiler got much better at analyzing and optimizing the program. So the compiler got faster and better. So while it is still slower than 1.4, it does produce better code.

To add: overhead for defer and for calling into C have been reduced pretty significantly with 1.8. Anything that does quite a bit of the latter may see a fair improvement in perf.

>Plugins are here, but on Linux only for now

The documentation says Linux only but the build flags seem to suggest it may work on macOS?

https://golang.org/src/plugin/plugin_dlopen.go:

    // +build linux,cgo darwin,cgo

Can someone with a Mac confirm?

Was already there but disabled due to https://github.com/golang/go/issues/18190#issuecomment-26525...

> The sort pkg now has a convenience for sorting slices, which will be a nice shortcut instead of having to define a special slice type just to sort on a given criteria, you can just pass a sorting function instead.

So you can do this now:

  sort.Slice(people, func(i, j int) bool { return people[i].Name < people[j].Name })

But what I think most people want is.

  sort.Slice(people, func(p Person) string { return p.Name })

Since that lends to things like this:

  //Sort first by age and then by name
  sort.Slice(people, func(p Person) (int, string) { return p.Age, p.Name })

But apart from reversing the resulting slice, how do you sort according to ">"? The current approach is more general and might be used with custom comparators. For example, it might be possible to implement the sort you have in mind with it.

Sort could have a reverse option, but for that to work well go would need overloaded functions, or at least types that you could define an ordering on, which would let you do

  a := ReverseOrder(10)
  b := ReverseOrder(20)
  
  a < b // false

  sort.Slice(people, func(p Person) string { return ReverseOrder(p.Name) })

Comparison functions are just not very user friendly when what you really want to do is just sort naturally based on a list of fields.

  sort.Slice(people, func(p Person) (string, string, string, int) { return p.Country, P.Gender, p.Name, p.Age })

turns into a pretty messy comparison function.

Not to mention, the key func aka DSU[1] approach is much faster when the comparison function is expensive to call.. imagine something like

  sort.Slice(numbers, func(i, j int) bool { return num_factors(numbers[i]) < num_factors(numbers[j]) })

vs.

  sort.Slice(numbers, func(n int) int { return num_factors(n) })

One needs manual memoizing or caching of this function call, the other can do it internally in a much simpler manor.

[1] https://en.wikipedia.org/wiki/Schwartzian_transform

They have sort.SliceStable for this I think, it's not much more verbose and is arguably clearer and more flexible as you can define exactly how the keys are compared (for example perhaps you want to downcase names before compare).

Compare the old way to do a multi-key sort:

https://play.golang.org/p/NJTVoeQkMt

With the new way:

https://play.golang.org/p/6ReQxHT1lR

it's a lot simpler and clearer and doesn't require a special slice type (as it did before), but lets you sort on multiple keys if you need to. Presumably sort.SliceStable is a bit slower and that's why they have a separate sort.Slice.

Note though that the old way using slice types does let you do something neater at the point of use at the cost of more setup:

    OrderedBy(language, increasingLines, user).Sort(changes)

which in some ways is more similar to what you desired?

Seeing this sort of hack added does make me think containers are the one big weak point in Go at present, they are a bit ugly, and special cases abound (append,delete,range,sort) - maybe in Go2 they could have something neater, more generic and more extensible. My hopes for Go 2 as a really uninformed language noob are a tidy up of the stdlib, variants and more elegant ways to manipulate containers (I won't say generics!), I would love to see things like magic comments and struct tags disappear too but that'll never happen. I'm pretty happy with the language otherwise, and would actually like to see Go get smaller and simpler over time.

ah, SliceStable does make it a little easier at least. I'd say you could just wrap that in a function, but you can't easily do that.

Sorting is probably the one area where I really miss generics in go.. because comparing and sorting IS such a generic thing to do. In my head I think, "Oh, so I just want to do

  hosts.sort(key=operator.attrgetter("os", "version", "address"))

and then proceed to write the 20 lines of code that lets me do that :-(

Just thought of one more way to do this which is neater - define functions on a simpler slice type:

https://play.golang.org/p/0YcxA-Ufs-

So your sorting becomes quite neat:

    sort.SliceStable(changes,changes.byLines)
    sort.SliceStable(changes,changes.byUser)

I think I might use it this way (haven't actually used this in a real app yet).

Perhaps something combining all of the things you've made use of? https://play.golang.org/p/8RDqjjZDB8

    GOPATH is optional now

GOPATH isn't optional; it just has a default value now.

If you're using anything in a vendor folder, you still need to set GOPATH to a parent folder of your /src/project.

ie. `vendor` is still ignored if it is outside GOPATH; and if you don't set GOPATH, it just defaults to `$HOME/go`. If you ignore GOPATH and don't set it, your code won't build.

You still need GOPATH for now.

(once vendor can exist outside of GOPATH we can really start moving forwards with things)

Is this likely to happen?

The tracking issue is here: https://github.com/golang/go/issues/17271

Maybe? I think broadly the answer is yes, but not very soon.

It'll probably be a timeline like:

    - Sometime between now and 1.10 / 1.11 - allow vendor outside of GOPATH
    - 1.11 / 1.12 - dep formally becomes part of the go toolchain
    - 1.12+ ?? - GOPATH stops existing or significantly changes form.

I'm just speculating based on the progress of dep and the discussions in various issue trackers.

Nothing is going into 1.9; it's not ready yet even as a candidate feature. 1.10 could see some changes, and beyond that there will definitely be some kind of changes.

...but probably not this year.

Yes sorry that was badly phrased. Should have been Setting gopath...

I'm confident they will gradually get rid of it. It was a convenient crutch at first but for those outside a mono repo quite limiting.

We've immediately used the graceful shutdown feature.

Is this in an open source project, any link to code using it?

I'm wondering if "The Go Programming Language 1e" (Donovan / Kernighan) is still relevant enough to be used as a first book for self teaching.

https://www.amazon.com/Programming-Language-Addison-Wesley-P...

Absolutely it is.

Go, the language, changed very little since 1.0, most of the improvements have been done on the runtime, GC latency and such.

The answer is yes. This is the go version 1 compatibility promise [0]. The maintainers have been very careful to not break compatibility, even if it means bug fixes.

[0] https://golang.org/doc/go1compat

I personally learned Go about 3.5 years ago myself by following tutorials on tour.golang.org, reading the Effective Go document and other blog posts here and there. Then I bought the book last year just out of curiosity. Honestly I find that the experience you gain by reading/writing Go code and consuming online content is more beneficial than the book. The book has some good parts, but I don't think it’s as practical as online resources.

> Honestly I find that the experience you gain by reading/writing Go code and consuming online content is more beneficial than the book.

This applies to almost all languages and technologies!

Yes, but sometimes it is much easier to get moving with a good textbook.

With Go, a few online tutorials and the documentation that comes with Go itself, were all I needed to get going. I am not sure if that was an explicit design goal, but I found the language very easy to learn.

I believe it was an explicit design goal. They wanted new employees joining from straight out of college to be effective within Google's codebase as soon as possible. Therefore the learning curve is pretty low if you already know another mainstream programming language.

It is. I already knew Go, but read it from cover to cover. It's a very nice book, and as was said, the Go1 compatibility promise will ensure it stays relevant for a long time.

Yes, read that book cover to cover, it is a really nice book which teaches you concepts, it might not contain the latest features of the language, but it is a great reference book nevertheless

Yes, Go maintains strict backwards compatibility, you can apply everything from the book no problem (unless it exploits a go bug which I don't think it does), though you'l miss out on the shiny new stuff.

I reckon h2 push (https://beta.golang.org/doc/go1.8#h2push) support will be big for web servers like caddy and traefik.

Caddy already has a few interesting ideas on how to use this: https://github.com/mholt/caddy/pull/1215#issuecomment-256360...

What is new in Go 1.8: http://www.slideshare.net/huazhihao1/what-is-new-in-go-18-72...

Best text version I found: https://github.com/golang/go/blob/master/doc/go1.8.html

If you want to see that page rendered: http://htmlpreview.github.io/?https://github.com/golang/go/b...

You mean https://tip.golang.org/doc/go1.8?

Also new: callback for client cert selection during TLS handshake.

https://github.com/golang/go/issues/16626

1.7 release was great for finally addressing the issue of ever-growing size of produced binaries. [1] Moreover, some additional improvements were promised in 1.8 which I was looking forward to.

But after upgrading to 1.8 I am now observing 3-4% binary increase vs 1.7, so the trend is again reversed back to fatter binaries. :(

[1] https://blog.golang.org/go1.7-binary-size

You can use upx[1] to compress the binaries. I usually can shrink my binaries by 75%.

Read more on this[2] blog post.

1: https://upx.github.io/

2: https://blog.filippo.io/shrink-your-go-binaries-with-this-on...

I see stop-the-world garbage collection pause times have been reduced to microseconds which is great. But for many applications the pause times for single threads still matter. Any numbers for that?

Official release blog post https://blog.golang.org/go1.8.

I'm seeing significant performance increases in my app (small RNA aligner). Haven't profiled yet, so not sure where the gains are coming from, but happy all the same.

> The DefaultTransport.Dialer now enables DualStack ("Happy Eyeballs"[1]) support, allowing the use of IPv4 as a backup if it looks like IPv6 might be failing

[1] https://tools.ietf.org/html/rfc6555

http://www.slideshare.net/huazhihao1/what-is-new-in-go-18-72...

so go is becoming more and more better for lower GC tasks

Looking at the c ffi improvements posted, I thought I'd check if there were improvements.

Time in ms to call a c function 2 billion times (lesser is better).

95536 - go 1.1.2

130105 - go 1.8.0

It is a rather crude example:

// plusone is the ffi

int x = 0;

while (x < 2000000000) x = plusone(x);

Here's the source https://github.com/dyu/ffi-overhead

With other programming languages:

4778

nim:

4746

rust:

5331

java7:

17922

java8:

17992

go:

130105

(edited for formatting)

Small stacks used for goroutines don't play well with calling C functions which assume huge stacks. That's price you pay for having nice scalability story. There might be other issues, which come from the fact that Go has elaborated runtime.

Yea it was a toy example. Still the overhead is steep for applications that call c ffi often.

The workaround is usually to batch your computations on the c-side (micro-rpc) and minimize the calls (like cockroachdb is doing)

nim is faster at calling c routines than c? That seems interesting... But probably the measurement errors are larger than 1%?

They're basically the same (its just a measurement error as you said).

Afterall, nim generates c files.

What's interesting is the nrvo optimizations that nim generates under the hood without much effort from the developer (on non-trivial codebases).

Folks, can someone enlighten me on how new Argument Liveness https://golang.org/doc/go1.8#liveness works ?

I mean, so now if you are in the middle of a long function, you cannot be sure anymore if parameters passed to that function are not GC'd? Or compiler does some hinting on "ooh, this param is not used after that point in function, lets mark it as `ready for GC`?

A little not so related question, what is/are the most used stack for web applications in Go? How common if at all would be a Go backend & React for instance frontend stack?

That's the beauty of Go. The "most used" stack is just net/http in the standard library. Other toolkits implement and extend its interfaces and work together quite well for the most part. Your choice of front end framework is really a matter of taste.

Cool, thank you for the insight!

I can't tell about "how common", but a react web client with a go backend API is exactly what I do on my main product, currently.

It still has a few problems I haven't managed to solve, though (but not related directly to go). For example, given the visible routing is handled by react-router, I haven't find a way yet to issue proper 404 status (I have a catchall route that renders web client page, then client router displays a "not found" page, but it will be a 200 status). Not that a big deal, because the web client is an application behind auth, and not some public facing pages.

I suggest you adopt a 3rd party router, rather than using pure Go standard library for this. https://github.com/julienschmidt/httprouter is the most popular one. It supports a custom 404 handler https://github.com/julienschmidt/httprouter/blob/master/rout...

Actually, go routing is not the problem, it's react routing that is : go router only knows about API endpoints, and have a catch all route to serve the web client, which then manage its routing by itself. The advantage in that is that the backend only needs to know about API routes, and the client is totally free to implement whatever routes it wants.

The code that does this for server-rendered js is in https://github.com/ReactTraining/react-router/blob/master/mo.... There's code to convert URL patterns to regular expressions in https://github.com/ReactTraining/react-router/blob/master/mo..., although that seems to work only for a single pattern and not all. Presumably you should find a way to convert all patterns to a single regex somewhere in the codebase and could use that to check the request in go.

Hmmm, indeed. I didn't thought about using react server side rendering and intercepting it to check which status to provide. Good idea, thanks!

No, I'll have to think about whether it's worth it adding a whole SSR stack just for that, in my app behind auth :)

Another great 3rd party router is Chi. https://github.com/pressly/chi

My company uses httprouter, but if Chi had been available when we started, we'd have used that instead. It follows Go's standard library API (httprouter diverges a little bit with its params) and adds support for Go's Context (which httprouter currently lacks).

I've been using gorilla's mux, precisely because it follows the stdlib API, will certainly have a look at Chi, thanks for the link.

A priory it seemed really ideal to use Go and React so that's good to know. That issue is something I'd hardly find out to happen if just looking up online, thanks for sharing.

Note that it's not really about using go, but more about implementing routing on client side : you lose http status for non api urls, whatever the backend language is.

But then again, when you have static pages for public facing (and indexed) pages, and you have proper http status for api requests, having or not http status on web client urls is not that a big deal, so that's probably why it's not often mentioned.

The only problem it could cause is if someone makes a deep link to somewhere in your app, it will return a 200 status and will be indexed by bots, probably indexing login form for just any url, so that's the annoying point (huge trolling possibilities, btw, there :) ).

Indeed there is this caveat and its exploitation possibilities. I appreciate the thorough insight, thanks for taking the time!

I can't help you with statistics, but it doesn't seem strange to me. I tend to start with (pure) Go for web services. If the frontend gets bothersome, I use something relatively lightweight, like Vue. If the backend gets a bit unwieldy, I add something minimal there, like Alice, httprouter/httptreemux or Chi. There's a lot of options on both ends, but I like to start small until I notice I'd have to start implementing whole stacks, at which point I might add a library close to what I had in mind myself. I work mostly on lower-level projects and services though.

I don't know about the most used stack, there are many ways to go depending on what you want to do, but I think the kitchensink approach of gigantic frameworks isn't commonly associated with Go, and I don't think Go really has one go-to stack like say Ruby on Rails. That does mean you'd have to be somewhat familiar with both Go and its community projects to make a decision.

Why is the latest stable version on their website still 1.7.5? Where can I download 1.8 installation for linux (not source code)?

I've just removed my previous version and then I realize there's no 1.8 on their website.

It's not released yet. The release machine is running.

What linux distro are you on? Most people on Linux tend to use their package managers to get updates, or is your distro too far behind on Go?

I'm using xubuntu, how do I manage go through package manager?

you can use 'godeb' to install the latest version of golang. it transforms upstream tarballs for the Go language in deb packages and installs them.

I use godeb: https://github.com/niemeyer/godeb

It packages the go release into .deb files, which you then can manage using standard Debian tools.

Note that since it scrapes the release page for what releases are available, it won't be able to download 1.8 until it, you know, has actually been released, and sometimes the release page changes format upon a new release and it may take a bit for godeb to be updated.

Ty, I will try it

I've just installed 1.8 through godeb, thank you!

I'd encourage you to look at building from source[1] rather than using package managers or binaries. It's quite simple, let's you upgrade/downgrade at will and importantly makes cross compiling to other architecture/OS trivial.

https://golang.org/doc/install/source

There are a few packages I always install directly from source, to avoid lagging. Golang is one of them.

If you're using Debian, or some similar system, chances are your package manager will never deploy something beneath /opt. So in my case I configure golang to install in /opt/golang/

On this particular host I have only three packages here:

      $ ls /opt/
      arduino-1.8.0
      calibre
      go-1.8

I am just leaving the release party in Hamburg, Germany and looking forward to simpler sorting and all the other improvements. Awesome stuff and awesome people!

random question here, but what are people using in the way of ORM/sql access with go? Just database/sql or are there any other good packages worth checking out. I don't expect a full-blown activerecord style ORM, but something that takes a bit of the pain out of mapping structs to records.

I've been looking forward to 1.8 to solve this problem. I wrote a small tool using the new `ColumnType` info that takes my SQL queries and generates code to query the database and unmarshal rows into an array of structs.

I would love to see that tool

https://github.com/jinzhu/gorm is quite ok

Check out https://github.com/vattle/sqlboiler. I prefer the STD lib usually. Also, look at https://github.com/jmoiron/sqlx for easier struct mapping.

Final release notes: https://golang.org/doc/go1.8

What is the best place to start if I want to learn Go? Any books? Tutorials?

Take the tour on their site. Check out gobyexample after that. Then read effective go.

Does anyone know the roadmap for Go 1.9?

There's some stuff at the end of these slides

https://talks.godoc.org/github.com/davecheney/go-1.8-release...

Here's a thread were the developers discuss what they intend to work on for the next release:

https://groups.google.com/forum/#!msg/golang-dev/Dn-pfWETUrM...

wow an official dependency manager. Didn't see that coming. Makes me happy.

Yay Mips32!

Linking to the Github release seems more like a grab for fake Internet points than a useful post.

A useful post would be waiting for golang.org to be updated and linking to the official release notes.

Edit: Thanks to whoever updated the link to point to something useful at least. Still would have preferred this came down until the release was actually posted.

For people that use Go, this is a useful PSA since they could grab it right now. for those that don't, this is uninteresting haha.

If only there was some kind of list that enthusiasts could join to get notifications like this.

An unfair, groundless projection on your part. Thanks for spreading a little more negativity today :-)

From the HN guidelines: Please don't submit comments complaining that a submission is inappropriate for the site.

It still hasn't actually been released yet though, 3 hours after your post, so it was a little premature :)

I'm as excited as the next gopher about Go 1.8's release, but for all practical purposes it hasn't been released yet. It's actually an incredibly frustrating submission for those of us excited to get the official binaries.

In addition to what schmichael mentioned: You linked to the general release history front page, which in the future will display nothing about the 1.8 release. You should have linked to a page that is not expected to change as time passes. This is why we use permalinks for blogposts rather than linking to the front page of some blog.

What about a comment complaining that a comment is inappropriate for the site?

Don't you have some errors to check for, or something? ;)

Draft release notes: https://beta.golang.org/doc/go1.8

Thanks, we've updated the link from https://github.com/golang/go/releases.

Not really, since there's a risk of new people deciding to use it whenever it comes up. It would be silly to say "alright, we get it, cigarettes are bad for you, can we stop harping on this please?"

Cigarettes kill people. Go is a programming language. There's no need to relitigate the issue in every Go-related post.

>Cigarettes kill people.

Very very slowly. Time spent fighting lacking programming languages also kind of kills people (steals time off of their lives).

> there's a risk of new people deciding to use it whenever it comes up.

And?

They're free to do so, if they think it can fit their needs.

Also, while Go isn't great, it isn't as terrible as some people make it. It mostly just isn't in any way exciting.

> They're free to do so, if they think it can fit their needs.

Which is why people need to be here every thread explaining the problems with Go.

Equating lung cancer and the lack of programming language features?

You might be in the wrong business.

So what?

Even I that disagree with some of the decisions that were taken,see a value in having people using Go instead of C.

And people explaining the problems with go allow potential future users to more accurately determine the value of using it.

Please don't do programming language flamewars on HN.

We detached this subthread from https://news.ycombinator.com/item?id=13662583 and marked it off-topic.

I was responding to "it's kind of useless to be beating the language up upon every release". My comment applies to literally any programming language release or other product release notification; it makes sense for people to discuss the pros and cons of a product every time it comes up, because A) things change and B) it might be the first time that someone has come across the product.

If minor version release notes are on-topic enough to get posted every single time, I'm not really sure how an attached discussion of the product in question (possibly involving criticism) isn't.

Hurray, Finally

Reply on news.ycombinator.com