I'd add to your first category that there's a lot of languages that adopt features that other languages have, making a ton of languages converge into basically the same language with some caveats. I don't remember the post now but I believe it was posted on HN some time ago, it was pretty insightful.

Anyway yeah, I'm glad Go is resistant to change.

No idea why you are getting downvoted, but I fully agree with that sentiment. There are already enough open source languages who seemingly want to be "everybody's darling" and implement any reasonably sensible feature request. One example: PHP's new "match" expression (https://www.php.net/manual/en/control-structures.match.php). Of course, I can understand that people like Go's more flexible "switch" better than the "traditional" C-style one, but if a language already has the traditional version, does it really have to add a new one which does mostly the same thing and in doing so cause headaches for thousands of developers who use classes or constants named "match"?

http://www.jerf.org/iri/post/2908 ?

(BTW, 2011 on that. I would not today agree with the statement "the Haskell community is the only community I know that is doing new things in the field of language and API design". I think Rust is doing interesting new things now. In 2011 they were still working on basic functionality. There's a couple of other interesting little up-and-coming languages.)

They resisted generics since day 1 on the basis of pragmatism. Now they included them on the basis of pragmatism?

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 believe I watched a talk from Rob Pike a few years ago where he mentioned that Go didn't have generics, not because they didn't want generics, but because they wanted a Go-like way of doing them, and wanted to spend a lot of time making sure they were done right.

I'm paraphrasing and I wish I had a source for you but I'm pretty confident I didn't make that up.

The FAQ said something similar - not that they were vehemently opposed, just that it wasnt a priority.

They never resisted generics as a concept. But they refused to implement generics in a way which compromised other Go values. Compilation speed was a big one. It's easier to implement generics if you sacrifice compilation speed (see: c++, rust, and iirc java). To their credit, it took the community a looong time to figure out how pull that off, because it's a hard problem. But I think they've done it.

FWIW Java doesn't sacrifice compiler speed for generics, they're entirely erased at compile time which is cheap.

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.

Are you sure you are not mixing up runtime impact with compiler speed? In Java generics are still part of the type system and are type checked which is a non trivial part of the compile time increase in generics typically.

Ah yeah, it seems I was...

They weren't ever firmly opposed to generics. Here's the FAQ from 2009:

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.

Java was created in 1995 and got generics in JDK 1.5 in 2004, I don't see anyone using this argument against Java. The weird fixation people have about Golang generics is really tiresome, that too after they have added generics after much deliberation.

Having watched this for a while, I would say, my fellow programmers, there's no need to build elaborate psychological defenses for why you don't want to use a language. Just don't use it. There's too many languages to know them all anyhow. You don't have to decide not to use something, then justify your decision with a few comfort blankets that you post every time the topic comes up. Just don't use it, and leave it at that. Or at the very least, skip posting your comfort blankets every time the topic comes up. There's a dozen languages I'd like to know better, and don't use them, and I don't run around giving myself "reasons" I don't learn them. The "reason" is simple: I don't have time. Languages are not an attack on you. Nobody who designed a language was even thinking about you when they created them.

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.

This here is the right sentiment, thanks for saying this. I would not bother the internet if my preferred feature is not present in Zig/Nim/Elixir.

You don't think it contributed at least a little to Go eventually adding generics?

No, I don't think the whining did a thing. It may seem impressive on HN, but compared to the continuous stream of whining any successful project receives about all sorts of things I suspect it was weighing less heavily on their mind than HN would think, because it's proportionally much smaller than HN thinks. Also, it's not like Go isn't already fairly successful; if I wrote a language as successful as Go I wouldn't exactly be crying myself to sleep every night, you know?

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 1995 and got generics in JDK 1.5 in 2004, I don't see anyone using this argument against Java.

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.

Yeah, this. In 1995, about the only mainstream language with generics was C++ with templates. (Same in 2000 when C# was released, incidentally)

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.

In 1995, Standard ML, Ada and Eiffel had generics and were hardly mainstream, C++ templates were still experimental, everything else did not used them.

A tad different from the computing world in 2009.

Is it really that much of a bad thing to iterate based on real world experience?

It is when they spend a decade insisting that they right and everyone else was wrong, then ended up doing it anyway.

Generics aren't a cutting edge feature that they wanted to see how it would develop. Their objection against it was ideological.

I don't really understand this type of criticism. People complained that Go didn't have generics, and now that they've delivered, people still want to complain for some reason.

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.

>they spend a decade insisting that they right and everyone else was wrong

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.

Why are you so bitter about it?

The Go team takes their time to thoroughly consider and conceptualize new features. That is a often forgotten virtue.

It’s not like they just had them ready to go at the flip of a switch and we’re just holding out.

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.

No, they didn't.

Exactly, just like firefox / chrome

you hear about firefox everywhere, everyday, and yet only has 3% marketshare