My apologies, there didn't seem to be much to address.
> the only people who would use Go are people who aren't aware of the last few decades of compiler research: people who think coroutines are a new idea and aren't sure whether generics are useful
This is simply untrue. Most developers I know that like Go have written tens of thousands of lines of code in other languages that do have generics and more advanced features. You seem to assume that because people disagree with you, that they must just be ignorant. How about if people disagree with you because we have different tastes in languages? Some people love LISPs, they drive me crazy. Some people love Python, I think it's merely ok. ... I love Go, and you hate it. That's ok. I don't think everyone has to like Go. But I don't tell the LISP people they should drop all this paren BS. I don't tell the Python people that they should add braces and static typing to their language.
> what is it that you think people who want Go to have generics don't understand?
...that generics are not needed in many of the cases where they're used. That YAGNI holds true a lot more often than they think. I had actually started coming to this conclusion (about generics) before I even started writing Go - and I'd already started using them less. Not having foo> in my code simplified it a lot, and given that most of the time I only ever implemented one version... it just wasn't worth defining a whole bunch of generic logic, when really I only had one concrete implementation that I'd ever use.
> My core complaint about Go: the authors simply have ignored decades of compiler research.
Not ignored, so much as "considered and discarded".
You say you've written Go and the lack of generics was a problem rather quickly. I have been writing Go for almost 2 years full time and 9 months on the side before that. Generics have almost never been a problem for me.
I see two possible reasons why we've had different experiences with Go:
Either you happened to be working on a project that really benefits from generics (something that makes heavy and repeated use of trees or vector/matrix math, etc)... or you were trying to write Go code the way you'd write in some language that does have generics.
If the former, well, that's truly unfortunate. Go doesn't work well for all projects. I wish it were better at that sort of thing, and maybe at some point we'll get some features that'll help out with those pain points. Maybe those features will be something like Generics... but I, for one, hope that it's not just generics like everyone else has generics, because I've been there, and I don't like it. There's a hell of a lot of code that doesn't need matrix math and left leaning red black trees and such. Go is good for all those projects.
If the latter, well, then you've really just shot yourself in the foot. This is like taking a minivan offroading in mud and then getting mad that it handles poorly. You have to use the language in the way it was designed. Yes, this means you probably have to write a min function every once in a while. Yes, this means you have to write a loop to test if a string is in a slice of strings. Just like you can't take the shortcut through the mud in the minivan. Just like you have to write type classes in haskell, or getters and setters in Java. Every language has its quirks.
All that being said, it's also completely valid fot you to say you just don't like Go. That's fine. I don't like a lot of languages, even though many other people do. But telling other people they're wrong or dumb for liking Go is not a position you can really justify. It's a matter of opinion, and opinions can't be wrong.