<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>munificent</author><text>This is exactly Larry Wall&amp;#x27;s point when he talks about the &amp;quot;waterbed theory&amp;quot;:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Waterbed_theory&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Waterbed_theory&lt;/a&gt;&lt;p&gt;Users don&amp;#x27;t often have the luxury of discarding essential complexity in the problem their trying to solve. So, if you don&amp;#x27;t give them the right tools to tackle that in your language, that doesn&amp;#x27;t mean they no longer need those tools. It just means they have to build them themselves first.</text><parent_chain><item><author>jasode</author><text>&lt;i&gt;&amp;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, &lt;/i&gt;&lt;p&gt;I don&amp;#x27;t know if adding generics to Golang is the right thing to do but I don&amp;#x27;t agree with how Cheney has framed it.  I wish programmers would use a more precise mental framework about &amp;quot;simplicity&amp;#x2F;complexity&amp;quot;.&lt;p&gt;It&amp;#x27;s not important if generics make the &lt;i&gt;&amp;quot;language specification&amp;quot;&lt;/i&gt; more complex.  What&amp;#x27;s really more important is if it makes the real-world &lt;i&gt;language usage&lt;/i&gt; more complex.&lt;p&gt;What matters is the sum of &lt;i&gt;total complexity&lt;/i&gt;:  the language spec + adhoc idioms&amp;#x2F;patterns&amp;#x2F;conventions&amp;#x2F;workarounds used in actual codebases.&lt;p&gt;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 &lt;i&gt;complexity in npm&lt;/i&gt; with dozens of modules for things like leftpad().  Or you can insist that &amp;quot;prototypes are simpler than OO&amp;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.&lt;p&gt;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&amp;#x2F;complexity in a &lt;i&gt;more holistic way&lt;/i&gt;.</text></item></parent_chain></comment><story><title>Go and Simplicity Debt</title><url>https://dave.cheney.net/2017/06/15/simplicity-debt</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>grok2</author><text>I think the author was actually referring to the fact that it makes the written software using Go more complex to understand and maintain. Quoting:
&amp;quot;...efforts to add templated types and immutability to the language would unlock the ability to write more complex, less readable software. Indeed, the addition of these features would have a knock on effect that would profoundly alter the way error handling, collections, and concurrency are implemented.&amp;quot;</text><parent_chain><item><author>jasode</author><text>&lt;i&gt;&amp;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, &lt;/i&gt;&lt;p&gt;I don&amp;#x27;t know if adding generics to Golang is the right thing to do but I don&amp;#x27;t agree with how Cheney has framed it.  I wish programmers would use a more precise mental framework about &amp;quot;simplicity&amp;#x2F;complexity&amp;quot;.&lt;p&gt;It&amp;#x27;s not important if generics make the &lt;i&gt;&amp;quot;language specification&amp;quot;&lt;/i&gt; more complex.  What&amp;#x27;s really more important is if it makes the real-world &lt;i&gt;language usage&lt;/i&gt; more complex.&lt;p&gt;What matters is the sum of &lt;i&gt;total complexity&lt;/i&gt;:  the language spec + adhoc idioms&amp;#x2F;patterns&amp;#x2F;conventions&amp;#x2F;workarounds used in actual codebases.&lt;p&gt;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 &lt;i&gt;complexity in npm&lt;/i&gt; with dozens of modules for things like leftpad().  Or you can insist that &amp;quot;prototypes are simpler than OO&amp;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.&lt;p&gt;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&amp;#x2F;complexity in a &lt;i&gt;more holistic way&lt;/i&gt;.</text></item></parent_chain></comment><story><title>Go and Simplicity Debt</title><url>https://dave.cheney.net/2017/06/15/simplicity-debt</url></story>