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