As he said in the article, neither seem to be problems which come up in practice. I maintain about twelve Go services running in production, and neither failure has cost me any significant amount of time.
What kills me is that generics (or any other programming language abstraction) are not problems, but problem-solving tools. Technically speaking, they are never needed, if your definition of "not needed" is "I can work without them".
You don't need anything beyond assembly language, really.
The thing with most tools and abstractions is that you don't appreciate them until you use them -- when you truly use them, not merely when you learn about them. Then you wonder how you ever lived without them. You don't know if failing to use an abstraction hasn't cost you a significant amount of time until you've embraced their use.
To me, this is a variant of the Blub paradox at work.
You don't need anything beyond assembly language, really.
The thing with most tools and abstractions is that you don't appreciate them until you use them -- when you truly use them, not merely when you learn about them. Then you wonder how you ever lived without them. You don't know if failing to use an abstraction hasn't cost you a significant amount of time until you've embraced their use.
To me, this is a variant of the Blub paradox at work.