3 ms·

Wouldn’t you just use sort.Slice? Doesn’t go having such type specific functions mean you don’t have to? Feels like that makes your codebase _less_ complex sin

Wouldn’t you just use sort.Slice? 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.

IshKebab 2y ago
Sorting using generics is faster and more ergonomic. That's why they are adding generic based sort to the standard library. https://pkg.go.dev/golang.org/x/exp/slices#Sort https://pkg.go.dev/golang.org/x/exp/slices#Sort Sort on its own is maybe not the best example because it's relatively easy to work around, but those workarounds quickly break down. Write me a function that returns the keys of a map in order without using generics... I'm not exactly sure what your second point is.
- cherry_tree 2y ago
  But go isn’t a language without generics, so I don’t understand the criticism
  - Capricorn2481 2y ago
    Well you were quoting a part that said "in a language without generics" and were questioning why that was bad, so that's what they responded to. But that used to be Go, and it got a lot of pushback when generics were introduced. It illustrates an issue people have where obviously good language features are rejected by a loud minority for seemingly no good reason.
  - School-Cotton 2y ago
    You were specifically asking about generics. If you wanted me to give an example of the usefulness of some other feature that Go refuses to add, I would. Yes, Go finally added generics (years too late). But the fact that so many people were opposed to them for so long illuminates something about Go culture that is still relevant.
School-Cotton 2y ago
> 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).

IshKebab 2y ago

Sorting using generics is faster and more ergonomic. That's why they are adding generic based sort to the standard library. https://pkg.go.dev/golang.org/x/exp/slices#Sort https://pkg.go.dev/golang.org/x/exp/slices#Sort Sort on its own is maybe not the best example because it's relatively easy to work around, but those workarounds quickly break down. Write me a function that returns the keys of a map in order without using generics... I'm not exactly sure what your second point is.

cherry_tree 2y ago
But go isn’t a language without generics, so I don’t understand the criticism
- Capricorn2481 2y ago
  Well you were quoting a part that said "in a language without generics" and were questioning why that was bad, so that's what they responded to. But that used to be Go, and it got a lot of pushback when generics were introduced. It illustrates an issue people have where obviously good language features are rejected by a loud minority for seemingly no good reason.
- School-Cotton 2y ago
  You were specifically asking about generics. If you wanted me to give an example of the usefulness of some other feature that Go refuses to add, I would. Yes, Go finally added generics (years too late). But the fact that so many people were opposed to them for so long illuminates something about Go culture that is still relevant.

School-Cotton 2y ago

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