Should Go 2.0 support generics?

This isn't like inheritance because there are already generics in Go; in all the built-in collections and channels. By releasing the very first version the designers admitted that generics are necessary.

I wonder if Go could avoid full genetics by supporting union types, as seen in languages like Ceylon and TypeScript.<p>For example, you could declare a function as Foo(thing string | []int). In other to use &quot;thing&quot; you&#x27;d need to do a type assertion. That&#x27;d allow &quot;generic&quot; functions where the author could decide which types to support, without going all the way to generics, which tend to open a few cans of worms. Same thing for structs and such. Obviously this has an impact on internal layouts; union values would need an internal type tag similar to interfaces.<p>With this in mind, I would hope that Go could get better pattern matching with destructuring; switch statements currently only allow you to extract one value, and it&#x27;s confusing that a single name is shared between all cases. But I&#x27;d love to be able to do something like:<p><pre><code> switch thing { case s := string: ... case [x, y] := []int if len(thing) == 2: ... } </code></pre> or whatever.<p>If we could get proper Rust-style enums on top of that (with appropriate pattern matching) that&#x27;d also be neat.

&gt; My point is that if Go is not going to have a story for templated types, then we need to own it, just like Haskell programmers own their decisions.<p>&gt; This isn’t simply a case of saying “nope, sorry, no generics for Go 2.0, maybe in another 5 years”, but a more fundamental statement that they are not something that will be implemented in Go because we believe there is a better way to solve the underlying problem.<p>ffs. tldr; yes. Add generics.<p>Come on, the feedback from the community has been overwhelming.<p>If we were going to &#x27;own&#x27; not having generics, we wouldn&#x27;t be having this conversation.<p>There&#x27;s a disconnect here, clearly, between the community and what the community wants, and what the language makers and designers want.<p>I think what Dave is advocating here is basically the &#x27;status quo&#x27; from golang 1.0 (ie. we&#x27;ll never have generics).<p>That hasn&#x27;t worked.<p>Lets not do it again.

Java and C++ programmers seem to like generics (templates in C++&#x27;s). Both languages needed to make some compromises, like Java&#x27;s run-time type erasure and the complexity of the C++ templates with the resulting compile times.<p>I&#x27;d like user defined collections to be easier in go, but that&#x27;s only one reason I&#x27;d like generics in go. I&#x27;d also like to remove one of the biggest arguing points over the programming language go, a language I think hits lots of important requirements. Getting it adopted by more teams will be easier and the whole go ecosystem will expand more rapidly if there was less to argue over.<p>I believe the go team when they say they haven&#x27;t solved all the problems with adding generics to go; however, worse is better and Java and C++ show that an approach to generics doesn&#x27;t have to be perfect to be very beneficial.

It&#x27;s interesting that it&#x27;s 2017 and this question still gets asked. Go having static types but no generics is the worst of two worlds: both dynamic languages and compiled languages with genetics have basic functional constructs like map&#x2F;reduce but Go insists on sprinkling interface {} everywhere and calls this &quot;solution&quot; good enough?

Hmmm, on one hand Golang&#x2F;generics seems to be a fairly popular discussion issue on (at least) HN.<p>On the other hand, it&#x27;s weird (to me) that people seem to seriously be considering Golang 2.0, when the current (1.0) doesn&#x27;t even have debugging working 100%.<p>Debugging on Linux with non-CGO seems ok. All other situations though have various levels of breakage. :(

If it can be implemented without significantly affecting pre-existing code, I see no reason why not. Generics are infinitely preferable to VerbBytes(), VerbString(), VerbFloat(), ...

well generic&#x27;s wasn&#x27;t the things why I stopped using golang. But I think many do because of it.<p>I stopped because of the error handling. try in rust&#x2F;scala is just too awesome to go back to basically a tuple that will always need to be handled.

go should support whatever stuff that could let me create a custom type safe container.<p>What is so hard to understand in that need ??

Absolutely not. Go is the new php and should stick to its original moto. Solve fmo problems and ignore everything else, go for it.

It&#x27;s important to remember how simple Java was in 1999. 10-15 years from now it&#x27;s likely Go will have all the features that people have been asking for. The earlier these features are added the better. As a project gets larger it gets much harder to make large changes. Do it now and while they&#x27;re at it they should fix the lack of good exception handling and a few other things that they will most likely have to address eventually.