I remember something similar with their approach to package management which they said wasnt necessary for years.
They really do seem to resist doing the right thing for as long as possible.
I remember something similar with their approach to package management which they said wasnt necessary for years.
They really do seem to resist doing the right thing for as long as possible.
I'm paraphrasing and I wish I had a source for you but I'm pretty confident I didn't make that up.
What they sacrificed was runtime correctness, because the type erasure lets you sneak invalid types into unsuspecting code. How much of a problem that's caused in the real world is debatable.
https://web.archive.org/web/20091113154906/http://golang.org...
> Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.
> Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.
12 years later, here they are.
I speak here to those who slag on Go and haven't so much as run "Hello World" in it. Those who have used it, especially for some period of time, and especially those who tried long enough to learn to program Go-in-Go (as opposed to Rust-in-Go or C++-in-Go, etc.), and decided they didn't like it due to their experience, I invite to continue discussing. You're not who I'm talking about here. Real experiences with the language are valuable contributions.
Those who haven't had real experiences are not making valuable contributions. "Lol generics, lol they realized they're wrong and I was right all along" and "Lol error handling is bad in Go" are not valuable contributions.
Cruise through the Go issues and look at all the closed issues. Then, for context, cruise through Rust's or Python's, or your favorite open source project of some size that isn't even a programming language. It's a constant deluge.
What did it was real use cases from using the language for a long time, offered by serious people who weren't just berating the designers. If you read the generics design, and especially if you read the whole history of the design, you can see where this has had an impact, where the features are tuned for the use cases presented by the community, and how the design has changed at least twice in a major way (depending on how you count, of course) as people work through the use cases.
You'll also come to understand better why it's not like you can just flip a switch and "turn on generics" and why everyone running around claiming it was easy is dead wrong. You can also learn some of this by paying attention to discussions of generics in other languages when Go is not a topic, because it'll become clear when not discussing Go, there's a lot of broken generics and strange edge cases and poor decisions made by existing languages that we have to live with forever. Not that all of them are broken, but, again, the idea that some care needs to be taken wasn't something the Go team just made up. There's plenty of languages, even big name languages like Java, that "flipped the switch and turned on generics" and it turned out not to be as awesome as presented, because it's a legitimately hard problem even in 2021.
Java was created in an age where very few languages with mainstream relevance had userland generics.
Go was not, and generics had already had to get (somewhat painfully) retrofitted in two of the above.
When Go came out in 2009, though, Java and C# had pushed generics into the mainstream. Additionally, they'd shown some of the problems with trying to retrofit generics onto a language and ecosystem that didn't previously support them.
A tad different from the computing world in 2009.
Generics aren't a cutting edge feature that they wanted to see how it would develop. Their objection against it was ideological.
I can quite believe that the Go team wanted to be sure that the approach made sense for Go, that it was the right solution to the right problem and to keep to their backward compatibility promise. Experience is a good teacher. I really don't know why it matters in the slightest that they didn't arrive at that on day one.
This just isn't how it happened. The Go team never said that they were opposed to generics. Their stance was (i) that it was not a top priority and (ii) that it was difficult problem and they'd take the time to implement generics correctly.
The idea that this is about one group of people finally proving that they're 'right' is a distortion based on viewing events though the lens of snarky comments on the internet.
There were trade offs and they didn’t have a solution on day one.
They’ve always said they were open to them with the right implementation.