Hacker News Reader

Comment by Crash0v3rid3 | Hacker News Reader

I've been writing Go for years and never came across a problem that made me want to have generics.

Anyone able to give me a simple example demonstrating why Go needs this?

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.

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.

Reply on news.ycombinator.com