[latronic_notron]

> But the standard generic does not fit very well with go type system, so....

Why not? Generics in Arrays/Maps/Slices fit perfectly in the language, and don't feel weird at all in Go.

[jstimpfle]

> Arrays/Maps/Slices

They are widely used data structures and so, in the opinion of the Go creators, justified separate specialized implementations in the Go compiler. In other words, there isn't actually a Generics system in the language (I don't actually know this, correct me if I'm wrong). For various reasons. There are quite a few talks and design docs from Rob Pike and Russ Cox if you look for them.

[latronic_notron]

Nope. They are generics, aka parametric polymorphism. And they fit perfectly within Go.

And generics aren't just for abstract data structures, there are other uses as well.

[jstimpfle]

I think you've misunderstood what I said. For example here: https://golang.org/src/go/parser/parser.go you can clearly see how e.g. token.MAP is a special case.

    func (p *parser) tryIdentOrType() ast.Expr {
        ....
        case token.MAP:
            return p.parseMapType()

There is a special-cased function parseMapType() function in the Go parser. This isn't generic at all. I mean even the syntax (as in func foo(bar map[String]int) ...) does not seem to be generic at all.

Yes, you can use any type as keys and values. But that's a far cry from an abstract system that lets the user define any parameterizable data type. And that's for good reason: By hardcoding just the most important parameterizable data types, the problems that an abstract system would bring can be avoided.

[latronic_notron]

Yes, I'm aware that they're a special case. What I mean is that this is exactly what is traditionally called "generics" or "parametric polymorphism" in PL literature. Go's Map/Array/Slice called "predefined generic types" in some literature.