Hacker News new | past | comments | ask | show | jobs | submit login

> 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




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: