Haha, touche. Your response is fair. My point was only that some people act like any successful language must have generics, which is demonstrably false IMO. I am not opposed to innovation and ergonomics (hence, my support for arbitrary precision ints), but we should carefully weigh the pros and cons of every new proposal, especially if it increases the complexity of the language and toolchain. In my opinion, the benefits of generics are outweighed by the cost of their complexity.

Well, we know now, contrary to what was said about generic-and-Go when Go came out: Go can apparently not do without generics.

What I always found hard to swallow is that Go's build in functions sometimes did have generics. Just you as a library/application writer were not allowed to create APIs with generics yourself.

Yep, seemed weird to me how (a form of) generics existed, but was exclusive to the stdlib/language.

If generics were unnecessary, why did the stdlib/language need them? Couldn't they just have lived with, e.g., make_map, make_slice, make_chan, etc?

Exactly. It was IMHO pretty authoritarian to say "you dont need generics" and then use it yourself in the standard lib.

But then Go is not a public place: it's private domain of Google.

I decided long time ago I dont want to learn a private tool without being paid.

And a separate copy of `append` for every possible type :)

First: I ninja-edited my comment after the fact with a thought that occurred to me after I posted, so apologies there.

Anyway, yeah, no argument there at all.

I'll be honest, as an outsider that's somewhat familiar with Pike's obsession with simplicity in Go, I'm actually a bit surprised this is getting in. It does seem like the kind of high-complexity feature that was deliberately excluded from the language as part of its overall design ethos.

But it really comes down to a weighing of pros and cons. Generics have the potential (though definitely not the guarantee!) to trade off developer complexity for compiler and toolchain complexity, and the preference on that choice is a personal one.

Well, then you also know he just didn't see any good implementations of generics, yet. Let's hope this gets good!

> I'm not sure "C didn't have it" is a good litmus test for determining the value of features

It can be a good test.

One reason why C is so ubiquitous is the simple binary interface. This makes it easy to reuse code since the libraries can be imported by every other language out there. C code is relatively simple and the compiled objects follow simple binary interfaces.

Adding features to languages almost always increases the complexity of these binary interfaces. Eventually they become so complicated that nothing will ever interoperate with software written in these languages. The increased language complexity reduces the reusability of software produced in that language.

C++ had this problem and Rust is following in its footsteps. Rust libraries are really only reused within the Rust ecosystem. Those that are meant to be universally reusable will no doubt offer a simple ABI that lacks all the benefits of the Rust language.

UNIX ABI.