←back to thread

“Go’s design is a disservice to intelligent programmers”

(nomad.so)
131 points apta | 1 comments | 25 Mar 15 21:48 UTC | HN request time: 0s | source
Show context
bsaul ◴[25 Mar 15 22:32 UTC] No.9266468[source]▶
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.

replies(1): >>9266925 #
kd0amg ◴[26 Mar 15 00:06 UTC] No.9266925[source]▶
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).

replies(1): >>9266992 #
bsaul ◴[26 Mar 15 00:20 UTC] No.9266992[source]▶
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.

replies(1): >>9267107 #
1. kd0amg ◴[26 Mar 15 00:50 UTC] No.9267107[source]▶
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).