So... you will still need 57 spots in the code where you define how to sort a type. Maybe my reference to sort.Interface is confusing people. When I say we ha

So... you will still need 57 spots in the code where you define how to sort a type. Maybe my reference to sort.Interface is confusing people. When I say we have 57 implementations of sort.Interface, that's 57 different types and/or different ways of sorting one of those types. So, like, sorting Machine by Name would be one implementation, sorting Machine by Name then OS then RAM would be another implementation. You write an implementation of sort.Interface for every type, and for each way you would like to be able to sort it. An implementation of sort.Interface just requires three methods: Len() int // return the length of the list Swap(i, j int) // swap items at indices i and j Less(i, j int) bool // return true if list[i] is less than list[j] It's the implementation in Less that determines the order. That's not really so different than what you're describing in Haskell, it's just not part of the type, it's a new type that you convert the original type into, to pass into the sort.Sort() function (and because the underlying type is a slice, which is a glorified struct with a pointer to an array, that also sorts the original value).