https://homepages.inf.ed.ac.uk/wadler/topics/gj.html
Before Featherweight Go, there was Featherweight Java.
So maybe a language designed in 2012 (v 1.0 release year), should learn from history instead of hand-waving it away as needless fluff.
> In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier.
https://github.com/golang/proposal/blob/master/design/go2dra...
And not all on the team were convinced, here Rob Pike,
> I think the transition to getting polymorphism into the language through generics is has still got some years to work through there's still things that don't quite work right
If you go back and watch the original Go announcement it was made abundantly clear that they believed Go did need generics at the time but that they didn't have the expertise to do it. Yes it is true that the book was already written on it, but that doesn't mean anyone on the Go team was familiar with it or had the time to become familiar with it. Programming languages do not require gods to design them. Imperfect humans can too.
The experts on HN who know all the ins and outs of generics could have contributed but, you know, shitposting "go doesn't have generics lol" was apparently a better use of their time. But it is certainly not for anyone else to do decide how they live their life.
Go culture is not welcoming to experts contributions, Rust, D, C#, Swift and others, heck even Java, are more open arms to language designers.
You'd think one of the HN experts would have shown up to offer that expertise, but I guess there was a lot of "go doesn't have generics lol" to get out.
The Haskell muscle had proven their skills already with Featherweight Java, in 2006.
But obviously "go doesn't have generics lol" comments were even more important. Imagine what would have happened to HN if that wasn't repeated multiple times daily for years!
Only about a year from when the Haskell guys lent their expertise and it landing in a release. That's actually fairly quick given that it was a pretty significant change under the hood and constrained by only two releases annually.
The Go team was always clear that they didn't have the necessary expertise internally and were relying on the open source community to lend a hand. Unfortunately, open source doesn't mean open willingness to contribute.