Go 2 Draft Designs
To be frank, I was for a long time on the camp that Generics is a much-needed feature of Go. Then, this post happened: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17294548" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17294548</a>. The author made a proof-of-concept language &quot;fo&quot; on top of go with generics support. I was immediately thrilled. Credit to the author, it was a great effort.<p>But then, after seeing the examples, e.g. <a href="https:&#x2F;&#x2F;github.com&#x2F;albrow&#x2F;fo&#x2F;tree&#x2F;master&#x2F;examples&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;albrow&#x2F;fo&#x2F;tree&#x2F;master&#x2F;examples&#x2F;</a>, I could see the picture of what the current codebase would become after its introduced. Lots of abstract classes such as &quot;Processor&quot;, &quot;Context&quot;, &quot;Box&quot;, &quot;Request&quot; and so on, with no real meaning.<p>Few months back, I tried to raise a PR to docker. It was a big codebase and I was new to Golang, but I was up and writing code in an hour. Compared to a half-as-useful Java codebase where I have to carry a dictionary first to learn 200 new english words for complicated abstractions and spend a month to get &quot;assimilated&quot;, this was absolute bliss. But yes, <i>inside</i> the codebase, having to write a copy-pasted function to filter an array was definitely annoying. One cannot have both I guess?<p>I believe Golang has two different kinds of productivity. Productivity within the project goes up quite a lot with generics. And then, everyone tends to immediately treat every problem as &quot;let&#x27;s create a mini language to solve this problem&quot;. The second type of productivity - which is getting more and more important - is <i>across</i> projects and codebases. And that gets thrown out of the window with generics.<p>I don&#x27;t know whether generics is a good idea anymore. If there was an option to undo my vote in the survey...