But to answer your question go has really mediocre support for a wide variety of problems. Some that burn me a lot is support for future/promises and support for modern lock free algorithms.
So you end up either writing non-optimal replacements, losing type safety or in some case code generation is used.
This doesn't make sense in Go. Nothing is asynchronous in Go, everything is blocking. You use goroutines to execute multiple tasks at the same time. That's a big part of what makes Go simple: it's a lot easier to understand sequential code than spaghetti callbacks and promises (it's somewhat similar to async/await in the JavaScript world).
Go’s unsophisticated type system makes it difficult to write a good standard generic data structure library such as a future/promise library.
That leads to people either writing a poor replacement, not using that style, or losing type safety. This is precisely what you would predict upon learning golang doesn’t have user defined genetics & ive had it bite me more than once in real projects.
I think people are used to futures etc, that's why the new concept feels strange.
I think the goroutines and channels are the biggest features which compensates for generics.
Goroutinue are very light weight. Zero size channel works like promise