Maybe adding generics to Go is about syntax after all

It's been three years since I started writing Go professionally and I think adding generics to Go is one of the worst ideas I've ever encountered. I love Haskell, and I much prefer hindley-milner type systems, type classes, and real sum types. I see the value of generics where appropriate. Golang, however, made the tradeoff to sacrifice anything near that level of abstraction, and it's success might largely be attributed to the approach-ability of the language as a result of that tradeoff. Retrofitting generics onto the language will be at it's best a death sentence for the principles and ergonomics of the language. One thing that has become clear to me as I have spent time with Erlang, Haskell, and Go is that it's much better to use the right tool for the job rather than trying to manipulate a tool to fit every use case, which is precisely what adding generics is all about.

Some discussion on why it might be not: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;golang&#x2F;comments&#x2F;9cjw98&#x2F;maybe_adding_generics_to_go_is_about_syntax_after&#x2F;e5b8akq&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;golang&#x2F;comments&#x2F;9cjw98&#x2F;maybe_adding...</a>

i haven’t written a whole lot of go, but from what i’ve done and what i see coming in go 2 i don’t really want to have to write a lot more. go felt like it was modern-vintage to start with memory management but also values&#x2F;pointers. with a heavy emphasis on multi return error handling instead of generics (Either), nil instead of Option, and mutability by default<p>and the future seems to be more weirdness. magic methods like handle. list comprehensions still uncertain. contracts sound like a backwards compatible break and duplicate of existing functionality.<p>i used go to use libraries and low memory foot print for my small projects. but i bet there’s simpler routes out there

Major props to Dave for realizing that his previous position (that adding generics had nothing to do the syntax) was mistaken, and for admitting so publicly.

This might be nice to use in the specific case. However, its important to note that in the general case, you need a type variable because it is used in multiple positions. In the function below (taken from the proposal), one is stating that T is the same type in all usages.<p><pre><code> func Join(type T strseq)(a []T, sep T) (ret T) </code></pre> This below version is different, each variable could be a different type (that satisfies strseq).<p><pre><code> func Join(a []strseq, sep strseq) (ret strseq)</code></pre>

I think the syntax is essential to the problem. A few days ago I wrote a quite similar post about the difference between Generics and Interfaces: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;arendtio&#x2F;77dd4df5f4b19dc69da350648434a88a" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;arendtio&#x2F;77dd4df5f4b19dc69da35064843...</a>

Why not adopt standard ML&#x27;s polymorphism semantics? Is there some type theory issue I don&#x27;t know about preventing that?

On the topic of &quot;syntax is important&quot; (though not related to generics -- other than by aside to the Result type) I&#x27;m still not a huge fan of the handle syntax -- I reckon something more similar to Rust&#x27;s .map_err() would be handled better because lots of people now use pkg&#x2F;errors[1] which has the boilerplate of<p><pre><code> if err != nil { return errors.Wrap(err, &quot;some message that is unique to this line&quot;) } </code></pre> and the handle construct doesn&#x27;t really handle (excuse the pun) this properly (you have to re-define handle each time or have a local variable or something similar). Which means that the new construct won&#x27;t actually be massively helpful unless the only thing you want to do is errors.WithStack or just bubble the error back up.<p>But I do get why they couldn&#x27;t get .map_err() -- because that&#x27;s something you can only really do if you have a Result type.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;pkg&#x2F;errors" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pkg&#x2F;errors</a>

Why not reuse Common Lisp macros?

If Go gets generics, maybe they’ll actually add an ‘implements’ keyword for interfaces and no more of this:<p><pre><code> var _ SomeIface = SomeConcrete{} var _ AnotherIface = SomeConcrete{} </code></pre> Just to see if you actually implemented all the signatures on the interface correctly.

I was at Gophercon and saw Russ&#x27;s video where he spent 30 seconds explaining what generics were to the audience and showed a half-baked example of the syntax they are considering. I&#x27;ve been using Go for almost 5 years now and have no desire to see generics introduced. It would ruin what is currently a very simple and easy-to-use language. Am I the only one who is hoping this whole thing fizzles out?