Go and Simplicity Debt
<i>&gt;But there is equally no question that adding these features to Go would make it more complex. [...] I have no doubt that adding templated types to Go will make it a more complicated language, </i><p>I don&#x27;t know if adding generics to Golang is the right thing to do but I don&#x27;t agree with how Cheney has framed it.  I wish programmers would use a more precise mental framework about &quot;simplicity&#x2F;complexity&quot;.<p>It&#x27;s not important if generics make the <i>&quot;language specification&quot;</i> more complex.  What&#x27;s really more important is if it makes the real-world <i>language usage</i> more complex.<p>What matters is the sum of <i>total complexity</i>:  the language spec + adhoc idioms&#x2F;patterns&#x2F;conventions&#x2F;workarounds used in actual codebases.<p>As an example, if you make a super simple language like Javascript in 1995 with hardly any features, what you eventually end up with is <i>complexity in npm</i> with dozens of modules for things like leftpad().  Or you can insist that &quot;prototypes are simpler than OO&quot; but you actually end up with a dozen OO-simulation libraries with different syntax out in the wild.  Instead of the overall JS landscape being simpler, it is more complex.<p>This does not mean you must put everything language feature including the kitchen sink into the language.  The lesson learned from history is to talk about about simplicity&#x2F;complexity in a <i>more holistic way</i>.