> 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 .
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.
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.
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
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.
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.
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.
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.