I would like to add on to this:

Generics may not be the correct solution, but I would really like a way to make collections which are general enough to be used by any datatype. As of now, I cannot do that without doing the typical `interface{}` approach.

The built-in data structures + channels are able to handle this, but if I just want a set of elements, what do I do? Make a `map[foo] bool`? If I see such a piece of code in an unfamiliar code base, I have no idea whether to test for key existence or whether I have to test whether the bool is true. A generic set would leave me puzzled and type unsafe[1]: What types could possibly exist in this set? A set of foos is not that hard to comprehend, and is in fact very much more straightforward to understand than a generic set, which in unfamiliar code may contain anything, or a mapping from foos to bools.

[1]: Rob Pike mentions in http://www.youtube.com/watch?feature=player_detailpage&v... that type safety is of high importance for Golang, but how does one achieve that if all the different datatypes I implement/need use `interface {}` where I have to cast all values afterwards? That seems very type unsafe, from where I stand.

You should be using map[T]struct{} for sets instead of bool. struct{}s use 0 bytes and there will be no confusion as to what the value is for.

Your puzzling "generic set" isn't what is usually meant by a generic set in a statically typed language.

A generic set would be defined disregarding the type of its elements: "set of ?s". However, a single instance of a generic set would only be allowed to contain members of a single type: "set of foos". This is called parametric polymorphism.

That's only true in a language with type inference and type aliases.

In Java, generics make your code completely unreadable, as content is buried in boilerplate. Map<Converter<Comment,Post>,ReadyState<CommentEnum> ops; for (Entry<Converter<Comment,Post>,ReadyState<CommentEnum> e: ops.entrySet()) { ...

In Go, generics would be an unqualified win for the author/reader. No one disputes that. The only dispute is over the compiler and runtime costs.

Generics (outside of C++'s templates which are a pretty odd duck[1]) generate very little compiler costs and little to no runtime costs (depending whether they're erased or reified), unless you decide to (optionally) trade some added compiler costs for some runtime improvements by generating type-specialized collections behind the scenes.

[1] and their cost is seriously compounded by the rest of C++, D has C++-style generics with a far lower compilation cost

Depends what you're comparing against. If it's a poor man's generic implementation in current Go using interface{}, then obviously there would be no extra runtime overhead if the compiler generated that for you in a type safe manner; but compared to manually specialized collections or the built-in generic collections, there is quite a lot of runtime overhead. Whether the compiler costs are manageable or not is up for debate.

The built-in collections can remain built-in if that gets you off. Same deal for manually specialized collections, except those aren't generic, so they remain not generic.

I think those are both rather bad solutions; I want generics precisely because they can provide equal performance to the built-in collections without the obvious drawbacks of a limited set of primitives or manually copying code. I'm just saying that "very little compiler costs and little to no runtime costs" is somewhat misleading, because there are significant runtime costs compared to those alternatives; Go needs code generation based generics, which are certainly doable, but incur significant complexity and runtime design issues.

> I want generics precisely because they can provide equal performance to the built-in collections

That is most definitely not the core use case for generics. They can be lifted into type-specialized collections, but the core point of generics is type safety.

Fair enough. Although my priorities somewhat differ from the norm, the document you criticized elsewhere does cite runtime overhead as a significant obstacle.

> the document you criticized elsewhere does cite runtime overhead as a significant obstacle.

And as I noted in my criticism it is completely wrong in doing so: the runtime overhead it notes is boxing in Java, ascribing it to generics.

But boxing is not a property of java's generics, it's a property of java's collections, java collections have required boxing value types since the first release (~1996), generics were only introduced in 2004. The boxing in java collections is orthogonal to generics.

In fact, one of the properties of C#'s reified generics is that it allows the compiler and runtime to avoid object (boxed) collections when it can use unboxed collections for value types.

True. The author is smart, and I would like to believe that he knew that reified unboxed collections would solve the space problem, but possibly be even worse than Java in time, since there is no JIT to inline repeated virtual calls to the same target. I can't guarantee that he did. ;p

That's a straw man I believe.

Furthermore, other languages seem to have got this right without the fabled runtime/compiler costs that the Go authors seem to talk about (see D for instance). What's funny is that there are runtime costs today in Go that could have been resolved by using generics. All interface calls are virtual calls, and cannot be inlined.

> No one disputes that.

Citation needed. I read and heard from many people that do.

I can't cite my claim that "no one" does something. I'm happy to see any example you provide of the Go team/nuts saying that generics are a bad language idea.

Russ Cox, a core Go dev: http://research.swtch.com/generic

That is not true in C++. std::vector<bool> is not really what you would have expected.

C++ templates aren't generic (or more specifically, aren't parametric) for a few reasons, one of which being that they contain a hidden overloading mechanism.