What I always found hard to swallow is that Go's build in functions sometimes did have generics. Just you as a library/application writer were not allowed to create APIs with generics yourself.

If generics were unnecessary, why did the stdlib/language need them? Couldn't they just have lived with, e.g., make_map, make_slice, make_chan, etc?

But then Go is not a public place: it's private domain of Google.

I decided long time ago I dont want to learn a private tool without being paid.

Anyway, yeah, no argument there at all.

I'll be honest, as an outsider that's somewhat familiar with Pike's obsession with simplicity in Go, I'm actually a bit surprised this is getting in. It does seem like the kind of high-complexity feature that was deliberately excluded from the language as part of its overall design ethos.

But it really comes down to a weighing of pros and cons. Generics have the potential (though definitely not the guarantee!) to trade off developer complexity for compiler and toolchain complexity, and the preference on that choice is a personal one.