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

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.

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.

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.

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

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