4 ms·

But you don't need to do that. It's a bit clunkier than generics, but it's usable: https://golang.org/pkg/sort/ https://golang.org/pkg/sort/

by ori_b 9y ago

hood_syntax 9y ago
I did a little research after I posted my original comment and came across that. It does seem usable even if it's not what I'd prefer
pcwalton 9y ago
You're still writing separate functions (implementations of sort.Interface) to sort different types.
- dualogy 9y ago
  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 9y ago
    > 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.
- ori_b 9y ago
  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 9y ago
    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 9y ago
      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.
- fauigerzigerk 9y ago
  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 })
krylon 9y ago
I have had the need to sort data rarely enough that it has not been a real problem to me (most of the time that data came out of a relational database that did the sorting for me). But when I did have the need to sort stuff, I have found it annoying. Even C has a more convenient solution for this problem. (Admittedly, Go's sort.Sort can work for data structures other than arrays/slices.) Like I said, it has not been a sufficiently large problem to really bother me, but it is not a pretty solution, IMHO. Of course, one might argue that the creators of Go knew that sorting things was not such a common problem for their target audience, and thus they made the trade off to make sorting suck in return for overall simplicity; Go's type system makes it practically impossible to implement a type-generic sorting function like C's qsort(3) without sacrificing performance or making the language more complex. So maybe that is one of the trade offs we have to make. I still wish for a better solution, even if that may be impossible without turning Go into another C++. And if you like C++, that is totally fine, it has a number of very big advantages. But then you do not need Go to become another C++ if you have the original right there; and even if you wanted to get away from C++ without giving up the benefits it offers, D looks like a more promising alternative.

But you don't need to do that. It's a bit clunkier than generics, but it's usable: https://golang.org/pkg/sort/ https://golang.org/pkg/sort/

by ori_b 9y ago

But you don't need to do that. It's a bit clunkier than generics, but it's usable: https://golang.org/pkg/sort/ https://golang.org/pkg/sort/

hood_syntax 9y ago

I did a little research after I posted my original comment and came across that. It does seem usable even if it's not what I'd prefer

pcwalton 9y ago

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

dualogy 9y ago
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 9y ago
  > 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.
ori_b 9y ago
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 9y ago
  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 9y ago
    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.
fauigerzigerk 9y ago
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 })

krylon 9y ago

I have had the need to sort data rarely enough that it has not been a real problem to me (most of the time that data came out of a relational database that did the sorting for me). But when I did have the need to sort stuff, I have found it annoying. Even C has a more convenient solution for this problem. (Admittedly, Go's sort.Sort can work for data structures other than arrays/slices.) Like I said, it has not been a sufficiently large problem to really bother me, but it is not a pretty solution, IMHO. Of course, one might argue that the creators of Go knew that sorting things was not such a common problem for their target audience, and thus they made the trade off to make sorting suck in return for overall simplicity; Go's type system makes it practically impossible to implement a type-generic sorting function like C's qsort(3) without sacrificing performance or making the language more complex. So maybe that is one of the trade offs we have to make. I still wish for a better solution, even if that may be impossible without turning Go into another C++. And if you like C++, that is totally fine, it has a number of very big advantages. But then you do not need Go to become another C++ if you have the original right there; and even if you wanted to get away from C++ without giving up the benefits it offers, D looks like a more promising alternative.