zlacker

>>apta+(OP)
I've had a hard time making up my mind with generics vs interface in go, but i think now that any compelling argument should be made using real world problem from a real world project.

Nobody is coding the sum of a list of integers for all the various integer types. People more likely use custom types anyway, and only have to create operations on those custom types ( except maybe for go language designers themselves). So there's always a suspicion that somehow there should be a way to code something clean using interfaces only.

>>bsaul+A4
People more likely use custom types anyway, and only have to create operations on those custom types ( except maybe for go language designers themselves).

People developing whole applications use custom types. People developing libraries meant for general use seem to prefer not limiting their stuff to working with their language's comparatively few built-in types (at least, that's how things seem to go in languages with generics -- Guava's BloomFilter should work with any type, even if that type was created well after Guava was written).

>>kd0amg+Xb
You're right, librairies developers are probably the one that should complain, and yet go is also famous for having a really extremely convenient standard lib (such as http), which means it should be possible. They are often built on top of a tiny set of orthogonal interfaces rather than generic types (see sort.Interface as an example of something quite low-level).

So that's why i'd like to see real-world problems that illustrate some concrete examples.