Generics were a pain point, but people have been crapping on Go on this forum while people out there are using it to build stuff. It's not a perfect language, but if you read any HN thread about it it's like it's impossible for people to go past the lack of generics or the existence of nil.
The existence of nil is also a design flaw. But you're right that no language is perfect and neither of these flaws keeps people from building tons of useful stuff with the language.
I think there is definitely gaslighting in the other direction too, which is what you're highlighting: lots of people know from experience that go is a super useful language, but then people come of as saying "your experience does not exist, it is not a useful language because of these big design flaws".
I suspect you’re talking about something I’ve seen, which is people will say that your experience in other languages isn’t directly applicable to writing code in Go because it’s a different language and ecosystem.
This seems like something newcomers need to hear sometimes, and it’s also somewhat irritating if in your case it doesn’t seem like that kind of issue. When generic advice for beginners gets misdirected then it can seem insulting, but I usually just try to remember that they don’t know me and beginner mistakes are worth checking for. I can choose not to be insulted.
Getting people to actually hear what you’re saying when they’re pattern-matching on common questions can be difficult. I think we should still assume good faith, though, and “gaslighting” implies malice.
Your more nuanced version of the argument is also wrong though. Experience from other languages is always applicable. Even for beginners, it is obvious and correct to ask "wouldn't we save a lot of repetition if we could write a generic version of this function instead of tediously rewriting the same thing for a bunch of types?". The correct and very reasonable response is "yes, but the designers of this language chose not to support that functionality in an effort to maintain simplicity". The right answer is not "no, this language is unique such that that technique is not applicable to it". That's gaslighting, and much worse when directed toward beginners who will just conclude that they must be wrong, when they aren't.
I agree with your last paragraph in general, but in this case that's not what was going on. Saying that the language would not actually benefit from polymorphism was not true, it was just a rationalization for leaving out a useful feature. It's the difference between "yeah that would be useful but we don't think the complexity it brings is worth it" vs. "that is not useful in this language for reasons you aren't wise enough to understand".
