Hacker News Reader

Comment by throw_m239339 | Hacker News Reader

> Still great to see things improving. It took mere 11 years.

Took that much time because of little clique of people outside the go team had way too much influence in the Go community. Let see if they dump the language like they threatened to, as the result of adding generics. Of course they won't.

Generics are there if one wants to, and they aren't like Java, but ADA. ADA got a lot of things right decades ago including the way tasks work from which Go routines should have taken a bit more inspiration .

Congrats to the Go time anyhow.

View on HN

I suspect a lot of people outside the go-team made comments, suggestions, and proposals. But honestly, thinking back damn few of them resulted in changes to the language.

If you'll recall back in the day there were several different vendoring approaches, but ultimately the go-team proposed and implemented their preferred solution.

Similarly there have been a million generics & error-handling suggestions but none of them were introduced. It's basically lots of distracting discussions, and it doesn't feel so much like a community project that is actually seeking outside discussion and ideas. (No shame in that, but the pretense is disappointing).

Personally I'm waiting for the fuzzing-support to land in 1.18. Fuzz testing is basically magical, and amazing in reporting problems even in code with "high coverage". The generics might be nice, but off-hand I don't see that I'll be needing them in the immediate future in any of my personal projects - but I fuzz-test the hell out of a lot of my projects (which largely revolve around interpreters and compilers).

I actually think this is one of the reasons I like go so much, and now write code in it almost exclusively -- it isn't really a community project, but rather a labour of love from a small number of genuine experts.

If it actually were a community project, I think we would have more of the "x := make(someType) vs. x := someType{}" TMTOWTDI that you find in other mature languages, and go would be weaker for it.

TMTOWTDI = there's more than one way to do it

Those community efforts may have not been have adopted, but that doesn't mean their existence hasn't informed the Go team's solution

I can only repeat the top comment from the "8 years of Go" thread [1]: the team made a different set of priorities, and was hugely successful in implemneting them, which also brought a ton of popularity. Golang is not my cup of tea, but I very much see the large and underserved niche it filled.

[1]: https://news.ycombinator.com/item?id=15671676

Rob was opposing generics from the start. People were pointing out the need more than a decade ago, but he was firmly saying no. Now he left the team.

> Rob was opposing generics from the start.

That's simply not true.

> he was firmly saying no.

I'm sure you cannot find a single instance where he firmly says no to generics.

He wrote in the FAQ that Go might get generics one day and that they are continuing to think about it.

Here he is arguing in favor of generics: https://www.reddit.com/r/golang/comments/jditu9/what_do_gene...

And he was the one who invited Phil Wadler to help with the generics design. From the Featherweight Go paper: "Rob Pike wrote Wadler to ask: Would you be interested in helping us get polymorphism right (and/or figuring out what “right” means) for some future version of Go?" https://arxiv.org/pdf/2005.11710.pdf

He's left the team? He seems pretty active even in this recent github thread.

Yes, he is no longer on the core team.

https://www.reddit.com/r/golang/comments/ksx4q1/what_happene...

Go doesn't/didn't have generics? Why?

It was commonly stated (or claimed) that they didn't know how to add generics without sacrificing both compilation time and runtime performance [1]. To my knowledge they ultimately didn't choose a particular implementation strategy and instead chose a design that allows multiple strategies as needed.

[1] https://research.swtch.com/generic

It also seemed like the original intent was to support generics and metaprogramming through code generation and AST manipulation, the argument being that code generation and AST manipulation are the most general way to build complexity and specialization from a simple set of primitives. I personally don't think that generics and generation are mutually exclusive, but if they were, I'd side with retaining simplicity over the new feature.

Because features in software don’t exist until someone adds them.

this is a really underrated comment. there's always a lot of entitlement when it comes to software. why doesn't x have y?

...because x doesn't have y yet....this stuff doesn't build itself, and it certainly doesn't get built overnight.

It’s pretty overrated really (even if grey). Mature projects and PMs treat submitted code as liabilities to be maintained, not free benefits. And every project is at the whims of its maintainer, who can absolutely reject any contribution they wish.

To suggest generics weren’t here sooner because no one wanted to make the pull request it is just dumb.

if someone's off on some tangent implementing a major feature without coordinating with the project maintainers and it subsequently gets rejected because it doesn't fit the constraints that they've stated for the feature...that's on them.

the go project is pretty upfront with how they go about deciding what will/wont get into the project, what process to follow, etc.

Posing it as "why doesn't go have generics" is bound to be reductionist, because it's too coarse of a question, and any real implementation winds up having a lot of nuance.

the question winds up just sounding entitled and petulant though, so if someone can't be bothered to ask a well informed question about why go doesn't have generics yet, the best answer really is "because it hasn't been added.", tautological as it may be.

Reply on news.ycombinator.com