It depends on how you define "need". Golang could be replaced with a notation for NAND gates and still be able to "do" everything it does now.

Yesterday I was in a pairing interview where I debugged and sped up some code. All-in-all I wound up with about 200 lines or so of Golang, including a lot of "yes, another loop" code. All I was doing, really, was mapping, forking and joining.

Meanwhile in Java, I could have gotten most of this in about 20 lines withJava 8 Streams and .parallel(). Generics make that tractable.

No, I had chosen Go for that problem. My reasoning was that most of the code I've read or written in the past 2 years has been Go, so it seemed like I should focus on using a language where I was warmest.

But in retrospect I would have preferred Java. That's my fault.

If you did, I wonder if you would regret choosing Java over Go for other reasons. I tend to find that no matter what language I choose, there's some parts of the code that I would prefer to be able to write in a different language.

> I tend to find that no matter what language I choose, there's some parts of the code that I would prefer to be able to write in a different language.

There is no final nirvana language. That is the awful truth of existence.

> no final nirvana language.

There isn't one...yet!

Perhaps their existing codebase is in Go and they need to use a utility. Perhaps they really like the performance of Go compared to Java. Perhaps they can't just use Java because of inertia or that no one else knows Java. Languages have warts, and wanting to remove one is not a bad idea.

I've seen so many abuses of interface{} in packages, especially for containers, that anything that can alleviate this problem is a step in the right direction. Even when they are not strictly necessary I expect generics to improve a number of packages. Then there is also the potential performance benefit, since generics should be strictly compile-time features - at least I hope that's the case for Go, I haven't checked the details of the proposal.

Dumb question, if you change an interface{} in go do you have to change everything based on it?

Presumably anything you've used codegen to solve; for instance, it'll probably make SQL libraries a lot nicer to use.

Code generation requires an additional build step. One thing I like about Go is that it feels like a scripting language (go run).

I guess writing a numeric library, like Python's NumPy, is a lot more convenient using generics. But I've never tried...

Lack of typed containers is a bit annoying for someone who touches go every now and then

Containers, operations on streams (map, filter, etc.), optional types (although those need tagged unions, something too advanced for golang), better concurrency handling (e.g. Task types), etc.

Proper higher level functions like map, reduce, ...

Oh, wow, you're right. OK, that'd be a huge win.

This is what I assumed generics were for. I haven’t been paying attention to the proposals but given the existing golang generics don’t support proper variance should I expect it with the user defined variance?

I wrote an Entity-Container system that really could've benefitted from a generic Get function. Instead I had to write on for each entity-type, even though they were the same except for different types.

Most places where the empty's interface is used now could benefit from it. Eg. the json package could state it always uses float64 for numbers (except when you tell it to use Number).

One example would be to return a single value from a method containing Either the value you want, or the error. That way you could chain a bunch of method calls together and just check for errors at the end instead of checking after each method call.