Hacker News Reader

Comment by p9idf | Hacker News Reader

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://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.

View on HN

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.

Let'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.

The 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.

> 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.

I 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.

Horrific may be hyperbole, but I have seen many an incomprehensible parameterized Java type definition.

> 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.

Go also has blessed flow control mechanisms, because you need flow control.

There's a significant difference in that Go's "designers" have not been asserting there was no need for in their language.

Reply on news.ycombinator.com