> 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 })

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

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

    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)

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.

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.

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.

> 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.

>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...

We've immediately used the graceful shutdown feature.

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