Notes on the Go2 Generics Draft
I&#x27;m glad I&#x27;m not the only one sad to see generics invading a perfectly good language.<p>Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn&#x27;t DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go&#x27;s &#x27;range&#x27; keyword shouldn&#x27;t be restricted to a handful of built-in types, but rather should support any type implementing an Iterator interface.<p>But Go was not designed to be perfectly consistent or to enable high-order abstractions. It just aims to be productive at scale, and that often means restricting the programmer. Go tries to be <i>non-magical</i>, and sadly that can take much of the whimsy out of programming. You can&#x27;t chain together operators in point-free style, or add a property to every &#x27;Object&#x27;, or directly increment a string, or anything like that. In other words, it&#x27;s a terrible language for code golfing. But that sort of code has no place in a production environment anyway. It&#x27;s &quot;clever&quot; code that gives the programmer a little dopamine hit when he writes it, and his co-workers a headache three months later. Those are misaligned incentives.<p>So I worry about generics because they let you abstract with wild abandon. They let you inject a little magic. And I fear that programmers will be seduced by their love of magic, and I&#x27;ll be the one who ends up paying the price.