> At runtime however they are simply passed as interface{} values wrapping the real values since the type soundness already has been proven.<p>So, this is some sort of limited Java-like generics with type erasure?<p>As someone who has only dabbled shortly with Go just to find out that he prefers a slightly more complex language, I find this sort of proposals tyring. I'd reconsider using Go if they finally got this thing right, but until then ...<p>I personnally would find the lack of generics acceptable, if go had (some sort of) algebraic types. But since the go team thinks these are useless either ... In some room in some building this probably makes some sense.
<p><pre><code> The compilation of a function that deals with a generic
type would need to be redone for each concrete type the
function is used with (including non builtin types) to
allow proper allocation etc.
</code></pre>
Isn't this essentially what's required to get type-safe "generic" code currently in Go, only with manual copy-pasting/codegen by the programmer instead of the compiler?
Uh oh, someone invented Java-style "generics" again...<p>Seriously, static typing without proper parameterized types isn't going anywhere; just do it and get it over with. Watching the Go-community is like a flashback to Steve Jobs arguing for the one-button mouse.