Yes it is precisely Go’s shortcomings that would require typical use of generics to also require reflection most of the time. You would want Rust traits (or Haskell type classes) or C++ style type traits and then the need for reflection is much reduced. So Go has painted itself into a corner where generics feel bolted on and less useful than generics in other languages. It’s still Go’s fault and people rightfully argue that they should prefer a different language.

The Go language itself is never its strength but it has a good runtime, wonderful standard library and tooling. People never picked Go for being an amazing language, but rather for these other things.

Interesting, thanks - is the problem you’re describing solved by Rust’s macros (eg derive) or are there further issues you see even there?

Thanks for that, nicely put, interesting angle.