> Wouldn’t you just use sort.Slice? That is what I meant by runtime polymorphism. It is slower. The fact that runtime polymorphism is so widely used despite be

> Wouldn’t you just use sort.Slice? That is what I meant by runtime polymorphism. It is slower. The fact that runtime polymorphism is so widely used despite being a crappy hack imitation of generics proves how useful generics is. Edit: Nevermind, sort.Slice doesn't use runtime polymorphism. It makes you pass in a comparator function. So probably not slower (assuming the function can be inlined), but less ergonomic. > Doesn’t go having such type specific functions mean you don’t have to? Feels like that makes your codebase _less_ complex since the core logic is handled by the language stdlib, not code written and maintained by your team. I'm not talking about the complexity for people using the code, but for the people writing it. Realistically not everything is in the stdlib and at some point you have to actually write some code. And at that point the features that make it easier to write code, like generics, make your life easier. (Also the Go sort package only has support for a few built-in types. What if you want to sort a slice of user-defined structs? Then you have to use runtime polymorphism via sort.Slice, which is slower for no good reason).