[pcwalton]

You're still writing separate functions (implementations of sort.Interface) to sort different types.

[fauigerzigerk]

For sorting slices you only have to pass one function:

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

[ori_b]

But this is something you often need to do for any non-trivial type, even with generics. There's a reason that C++ std::sort<> takes a comparator, or why Rust requires you to implement the 'Ord' interface.

Again, it's a little clunkier in Go, but not unusably so.

[pcwalton]

You need to define how to order things in other languages (though not in languages where you can automatically derive implementations like Haskell or languages with built-in polymorphic comparison like OCaml) but you don't need to define how to swap elements over and over.

[ori_b]

Yes, I'm aware. That's the clunky part that I was referring to (although, you can still avoid it for slices, and simply pass a single compare function.)

Go is far from my favorite language, but the sheer amount of bad criticism by people that clearly don't use the language annoys me.

[dualogy]

A little boilerplate hasn't killed anyone. If you're talking about "100s of different Enterprise Business Objects (TM) structs", something is probably off in the overall program design and/or code-gen should probably be introduced regardless of the 'sort' (and related typically-generics use-cases) question, as that sounds like something to be largely derived from pre-existing schemas of some sort..

[pcwalton]

> A little boilerplate hasn't killed anyone.

It's annoying, especially since basic generics are simpler than interfaces.

> If you're talking about "100s of different Enterprise Business Objects (TM) structs"

I don't write enterprise software. I sometimes need to sort things.