<story><title>The Next Step for Generics</title><url>https://blog.golang.org/generics-next-step</url></story><parent_chain><item><author>jasonhansel</author><text>Go really should have learned 2 lessons from Java 5:&lt;p&gt;1. People will eventually want generics
2. Retrofitting generics onto an existing language is hard and leads to unusual problems&lt;p&gt;(edit: I&amp;#x27;m glad Go is doing this, but...Java learned this in 2004.)</text></item><item><author>cies</author><text>I cant help feeling it is a missed opportunity to add generics to Go this late. A mistake that is copied from earlier languages (C++, Java), a mistake similar to other mistakes Go chose not to solve at it&amp;#x27;s inception, like: having implicit nulls (C, C++, Java, JS, C#), lack of proper sum types (C, C++, Java, JS) and only one blessed concurrency model (JS).&lt;p&gt;While I think I get the reasons for these decision in theory, make a simple-to-fully-understand language that compiles blazingly fast, I still feel it&amp;#x27;s a pity (most) these issues where not addressed.</text></item></parent_chain><comment><author>kjksf</author><text>There&amp;#x27;s is a design document for Go generics.&lt;p&gt;If you see &amp;quot;unusual problems&amp;quot; with the design, then tell us what they are.&lt;p&gt;Otherwise it&amp;#x27;s just shallow pattern matching &amp;quot;Java added generics late, they had problems, Go added generics late therefore they&amp;#x27;ll have problems too&amp;quot;.&lt;p&gt;Counterexample: C# added generics late and it&amp;#x27;s perfectly fine design.&lt;p&gt;The reason Go team is not rushing to implement generics is precisely so that the design makes sense, in the context of Go.&lt;p&gt;Over the years Ian Taylor wrote several designs for generics, all of which were found to not be good enough.&lt;p&gt;They are doing it the right way: not shipping until they have a good design and they didn&amp;#x27;t have good design when Go launched.</text></comment>
<story><title>The Next Step for Generics</title><url>https://blog.golang.org/generics-next-step</url></story><parent_chain><item><author>jasonhansel</author><text>Go really should have learned 2 lessons from Java 5:&lt;p&gt;1. People will eventually want generics
2. Retrofitting generics onto an existing language is hard and leads to unusual problems&lt;p&gt;(edit: I&amp;#x27;m glad Go is doing this, but...Java learned this in 2004.)</text></item><item><author>cies</author><text>I cant help feeling it is a missed opportunity to add generics to Go this late. A mistake that is copied from earlier languages (C++, Java), a mistake similar to other mistakes Go chose not to solve at it&amp;#x27;s inception, like: having implicit nulls (C, C++, Java, JS, C#), lack of proper sum types (C, C++, Java, JS) and only one blessed concurrency model (JS).&lt;p&gt;While I think I get the reasons for these decision in theory, make a simple-to-fully-understand language that compiles blazingly fast, I still feel it&amp;#x27;s a pity (most) these issues where not addressed.</text></item></parent_chain><comment><author>Ericson2314</author><text>Go is just Java repeated as farce. The histories are almost identical with ~10 years lag.&lt;p&gt;We all called this when Go was created, too.</text></comment>