
Go Proposal: Blank types as an alternative to generics for Go 2 - c8g
https://github.com/golang/go/issues/21132
======
stewbrew
> At runtime however they are simply passed as interface{} values wrapping the
> real values since the type soundness already has been proven.

So, this is some sort of limited Java-like generics with type erasure?

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

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.

------
al2o3cr

        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.
    

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?

------
andreasgonewild
Uh oh, someone invented Java-style "generics" again...

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.

