5 ms·
Your argument is not clear to me. However allow me to share some of the Go authors' thoughts about generics: http://research.swtch.com/generic http://research.
by p9idf 15y ago
Your argument is not clear to me. However allow me to share some of the Go authors' thoughts about generics:
http://research.swtch.com/generic http://research.swtch.com/generic
http://commandcenter.blogspot.com/2011/12/esmereldas-imagination.html http://commandcenter.blogspot.com/2011/12/esmereldas-imagina...
I am inclined to agree with them. I like writing Go programs quickly, but not at the expense of compilation speed† or execution speed. The point of Go is to be fast. If I valued programming speed for a particular program, then I would use the right tool for the job and choose a language other than Go.
† Though considering the speed of Plan 9-style compilers, I can't imagine at what scale this would begin to be a problem.
- ootachi 15y agoAs 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]
- masklinn 15y ago> However allow me to share some of the Go authors' thoughts about generics: While forgetting Go has blessed in-runtime generic types because it turns out you really need generics.