Other than that, generics have not really solved an actual problem for me in the real world. Nice to have, but too mush fuss about nothing relevant.
It's very subjective but my gut feeling is they probably didn't expand their community much by adding generics to the language.
No, it still feels like programming with a blindfold on and one hand tied behind my back. I truly don't get it. I've worked with a lot of languages and paradigms, am not a zealot by any means. Other than fast compiles and easy binary distribution, I don't see any value here, and I see even experienced Go programmers constantly wasting time writing unreadable boilerplate to work around the bad language design. I know I must be missing something because some people much smarter than me like this language, but... what is it?
If you "other than" two huge-for-many-use-cases good things, sure, it might look bad. ;)
But I would add good overall performance and in particular straightforward flexible concurrency support to the list of good things.
And IMO once you're in the set of "things with good perf" there's generally a lot of "boilerplate" of one sort or another anyway.
I'm more comparing it against languages like Kotlin and Swift, or even Scala.
I still remember people gaslighting everyone that any feature Go had was ESSENTIAL, and every feature Go didn't have was USELESS or too complicated for mere mortals "delivering value".
And the fast compiles at least are in big parts because the language is so horrendously basic. Can't get hung up on checking type constraints if you barely have any.
I'd add what I think is perhaps its most significant benefit to the list: Go fully solved the function coloring I/O problem in a way few other languages (Erlang/Elixir and ... Bend? Others?) have.
That's adjacent to the concurrency benefits in the parent comment, but a little different: allowing procedural, non-colored code to be efficiently concurrent over I/O without introducing function coloring or requiring people to code specifically to an event loop/IO multiplexer in some other way requires good concurrency support in the language, to be sure. However, getting rid of function coloring while providing efficient concurrent IO also requires: a solid stdlib of IO capabilities; a very very good runtime that can coalesce goroutine-concurrent IO into multiplexing OS primitives in the same way a function-colored event loop would (while pre-empting/scheduling in a reasonable way that mitigates unexpected blocking); a strong "critical mass" of libraries to talk to common IO-ful systems; a strong community convention of "we will generally prefer reimplementing IO drivers in Go rather than binding/Cgo-ing in foreign code".
It's when you combine all of those that Go shines as a platform for concurrent (usually network) IO.
I'd say this is still the norm in discourse around Go, it's just that the goalposts have moved somewhat since it has more features now.