<story><title>My Go Resolutions for 2017</title><url>https://research.swtch.com/go2017</url></story><parent_chain><item><author>xyzzy_plugh</author><text>I see where you are coming from, but that isn&amp;#x27;t the go way.&lt;p&gt;Switch on arbitrary types, followed by typecasting? That&amp;#x27;s the go way. No surprises. Explicit instead if implicit behavior.</text></item><item><author>bsaul</author><text>Along with generics, they should probably also reconsider algebraic data types, such a enums with values. This is &lt;i&gt;the&lt;/i&gt; best feature swift adds to the table hands on, and it seems to me as it&amp;#x27;s pretty orthogonal to the rest of the language ( although it carries a lot of other features with it, such as pattern matching).&lt;p&gt;They wrote that they considered it to be redundant with interface programming, but really i don&amp;#x27;t understand why. Interface is about behavior, not data. An int doesn&amp;#x27;t &amp;quot;behave&amp;quot; like one, it &lt;i&gt;is&lt;/i&gt; one. And something that&amp;#x27;s either an int or an array of string, doesn&amp;#x27;t &amp;quot;behave&amp;quot; like anything you&amp;#x27;d want to describe with an interface...&lt;p&gt;As an example, one should see how protobuf &amp;quot;one of&amp;quot; messages are dealt with in go : switch on arbitrary types followed by manual typecasting. That&amp;#x27;s just gross...</text></item></parent_chain><comment><author>coldtea</author><text>If anything, ADT&amp;#x27;s would make it even more explicit. And pattern matching will make it impossible to miss cases.</text></comment>
<story><title>My Go Resolutions for 2017</title><url>https://research.swtch.com/go2017</url></story><parent_chain><item><author>xyzzy_plugh</author><text>I see where you are coming from, but that isn&amp;#x27;t the go way.&lt;p&gt;Switch on arbitrary types, followed by typecasting? That&amp;#x27;s the go way. No surprises. Explicit instead if implicit behavior.</text></item><item><author>bsaul</author><text>Along with generics, they should probably also reconsider algebraic data types, such a enums with values. This is &lt;i&gt;the&lt;/i&gt; best feature swift adds to the table hands on, and it seems to me as it&amp;#x27;s pretty orthogonal to the rest of the language ( although it carries a lot of other features with it, such as pattern matching).&lt;p&gt;They wrote that they considered it to be redundant with interface programming, but really i don&amp;#x27;t understand why. Interface is about behavior, not data. An int doesn&amp;#x27;t &amp;quot;behave&amp;quot; like one, it &lt;i&gt;is&lt;/i&gt; one. And something that&amp;#x27;s either an int or an array of string, doesn&amp;#x27;t &amp;quot;behave&amp;quot; like anything you&amp;#x27;d want to describe with an interface...&lt;p&gt;As an example, one should see how protobuf &amp;quot;one of&amp;quot; messages are dealt with in go : switch on arbitrary types followed by manual typecasting. That&amp;#x27;s just gross...</text></item></parent_chain><comment><author>bsaul</author><text>If you have a look at swift, it&amp;#x27;s also very explicit, and non-magical ( which is why i like it so much). The difference with go is that you can&amp;#x27;t make any type error when unwrapping the enum, because the compiler knows what are the different possibilities.&lt;p&gt;I see no reason for go not to adopt it, in all honesty. it&amp;#x27;s nothing like generics, because it doesn&amp;#x27;t seem to add complexity to the rest of the language ( imho ).</text></comment>