4 ms·
I agree with you strongly. No generics please. It is already hard enough to try to steer a group of developers towards a shared vision without giving them the
by flippinburgers 5y ago
I agree with you strongly. No generics please. It is already hard enough to try to steer a group of developers towards a shared vision without giving them the ability to show off how "smart" they are.
Abstractions in libraries? Ok maybe.
In the higher level code that the vast majority of programmers actually write? No. Thank. You.
Besides, interfaces cover the majority of generic problems on the ground.
- mikepurvis 5y agoIsn't that a fairly easy policy to enforce, though? Basically you blanket ban them in your linter, and only create exceptions for specific cases like containers, parsers, situations where it saves you a cast, whatever. I know that doesn't help you when you have to interact with the larger Go ecosystem on Github, but at least within an org, it shouldn't be terrible. Certainly the culture of golang is well established— millions of lines of it have been written generic-free, so I'd expect that it will only be applied where it really is an obvious improvement.