4 ms·
As I stated below, Go's lack of generics isn't buying the language anything from an implementation standpoint. What Russ Cox is missing is that, absent some way
by ootachi 15y ago
As I stated below, Go's lack of generics isn't buying the language anything from an implementation standpoint. What Russ Cox is missing is that, absent some way to write generic code, programmers will end up paying the exact same taxes via their handwritten non-generic code.
Consider, for example, a binary search tree that can be instantiated with keys of int type or keys of string type. There are two ways to implement this in Go: (a) use an interface and dispatch calls through a vtable; or (b) implement the tree twice, once for ints and once for strings. But note: these two implementation strategies carry the exact same costs as the corresponding implementation strategies for generics! In the case of (a), the programmer is performing boxing via interface types, while in the case of (b), the programmer is performing code duplication. So not having generics doesn't relieve Go programs of compile-time or runtime overhead in any way; it simply increases the burden on the programmer.
- eternalban 15y agoLet's take case (a) -- that's the approach I adopted when implementing a Splay tree, introducing a Comparator interface. Granted it is a bit of a pain to write IntComparator, LongComparator, etc., but given that Go is not an object oriented language e.g. all types do not support a (hypothetical) CompareTo(other T), it is not clear to me how would the availability of generics would help in this case. For basic type coercion, yes, it is a pita to write boxing code, and clearly a maintenance issue as well.
- ootachi 15y agoThe simplest way that they would help your example is by ensuring that you can't add a mix of ints and strings to the same splay tree. Presumably this would cause a runtime failure. Generics add type safety.
- deleted 15y ago[deleted]
- enneff 15y ago> Go's lack of generics isn't buying the language anything from an implementation standpoint. But it does buy us a lot from a code complexity standpoint. C++ templates and Java's generics have a horrific effect on readability and comprehensibility, two of Go's primary goals. Generics are hard. If/when we do them, we'll get them right.
- ootachi 15y agoI don't think Java's generics have a "horrific" effect on readability and comprehensibility, except for the fact that they have use-site variance instead of definition-site variance. (The ? existential type is kind of screwy too.) But neither of us are going to be convinced otherwise.
- enneff 15y agoHorrific may be hyperbole, but I have seen many an incomprehensible parameterized Java type definition.
- deleted 15y ago[deleted]