zlacker

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+(OP)
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.

>>bsaul+51
It's no surprise that an HTTP library doesn't have issues with the lack of generics -- it shuffles text around. Reusable data structures are the obvious case for genericity, and I don't see many in the docs. Once you have a higher-order language (whether via objects or first-class functions), some control structures become data you might want to use generically. Looking over Java's stuff also shows some interfaces one might want to parameterize over a type (e.g., Comparable -- what can you compare this to?, Future -- what type will we get from it?). Haskell also offers a lot of examples of really exercising polymorphism (like lenses, but those maybe aren't appropriate for Go).