[ppeetteerr]

Not a Go programmer but I can say that Generics were important for me to consider adoption of Go. Now that they are present, it's a legitimate language. Whether they make code messy really depends on how they are being used.

[xyzzy_plugh]

It's been a legit language for years. Frankly I've enjoyed the lack of generics acting as a filter function for astronaut engineering.

I don't want to read through a heavily templated, generic code base when concrete, simple types will do. Go is so easy to read and reason about that I'm genuinely afraid of any change which could affect that.

The best advertisement for avoiding generics in Go despite their availability is the fact that they won't appear in the standard library for some time, and that the language maintainers believe it will take years to understand how to use them appropriately.

[62951413]

I'd wait until we see how the updated standard library looks like. In Java they had to invent Streams. Scala/Kotlin didn't repeat that mistake and so their collection APIs are more natural to work with. Historically golang has repeated most Java mistakes so I don't hold my breadth.

On the positive side, now Either/Try-like composable types are possible. So even if they insist on not having exceptions they could clean up error processing.

[choeger]

> Now that they are present, it's a legitimate language.

I second that sentiment, but I would have to look into the specifics. Generics ala Java aren't really that attractive when Rust mainstreams ML-style polymorphism with Haskell-style overloading.

[spion]

What about `if err return err` everywhere?

[johnisgood]

I like them personally. It is easy to ignore them, and if you want them, they are there.