Hacker News new | ask | show | jobs
by darksaints 1892 days ago
For a language that has taken extreme measures to exclude generics because they are deemed to complex, this proposal is absolutely surprising to me. And I'm still not sure what practical benefit comes from it.
5 comments

For a language that has taken extreme measures to exclude generics, Go seems to have an awful lot of accepted design proposals for generics.
Practical benefit in the sense of "you get a free pony" or "before you didn't have closures and now you do"? None.

Practical benefit in the sense of "you get to express something in a shorter, more uniform way"? Some.

I'm not sure why this would be posted to HN, honestly; it's a very "inside baseball" thing. In my personal experience this would save a lot less than one line per module. I've encountered this, but it's infrequent. The benefit is very minimal in practice.
Imagine you want to create an instance of a struct with many string and int pointer fields. This is actually a big pain in the ass in Go (the AWS SDK offers an aws.String helper for this reason).
While true, generics are on the way to be released on the end of the year as first step.