zlacker

[return to "Go(lang): Robust generic functions on slices"]
1. gslall+Ng3[view] [source] 2024-02-24 09:47:08
>>signa1+(OP)
> func Index[S ~[]E, E comparable](s S, v E) int {

After seeing this signature, I think that Go is giving up on it's simpleness principle.

◧◩
2. richri+Aj3[view] [source] 2024-02-24 10:31:59
>>gslall+Ng3
I was quite upset that they introduced generics. It is slow marching into C++ like look and feel and all the eyesore that it entails.
◧◩◪
3. quickt+Zk3[view] [source] 2024-02-24 10:53:10
>>richri+Aj3
In C# I feel you needed generics because there was no resizable array without casting from object (the Pareto 80-20 use case) and later async and Task<T> but I don’t think these problems apply to Go so it could have done without it (maybe!). Non userspace generics may be where it is at to ease suffering in places.

As a language design though Elm remains remarkably simple with parametric polymorphism (aka Generics) but it needs other design choices to do so. Elm is the Go of Haskell :-)

[go to top]