As someone who was an earlyish adopter of golang back in 2012 and who bounced off it hard because the amount of duplicative work across my team was just too much, I applaud this. I know it sucks to make something with a specific intent in mind (and I do agree with Pike's story on why golang was designed without generics -- you can live without them and Java's nasty implementation of them is certainly grounds to avoid them entirely), and to see that intent misinterpreted (often in bad faith) and memed and basically turned into a scapegoat against the entire language. You don't want to let those people win when there's nothing wrong with your design and people are mostly just being whiners. You know you did a good job, and the adoption of your language shows that many people agree with you.

But I'll be real. Programming in golang is not fun. Does it produce fast, safe, scalable code? Of course. But it sucks to work in because instead of being able to operate on the DRY principle, golang seemingly purposefully eschews it. It many ways it's ahead of its time (support for monorepos years before that was the new hotness; channels; innovative garbage collection; etc), but it really is far behind the times when it comes to generics.

The inability to write a simple function on a generic collection without resorting to brittle runtime type-checking is, to be blunt, bullshit. It's bullshit because the language itself allows it (`make`, `range`, `struct` literals, for example), but the implementation is hidden from the user. There were good reasons to do this! That doesn't make it any less painful for the user.

Yeah yeah yeah, the language wouldn't function without `make` and `struct` literals, but that's exactly the point: the _concept_ of generics has to be in the language for it to work the way it does, and hiding it from user is just completely unfair and always has been.

So good on them. Hopefully the implementation is a good one.