You seem to be conflating type-parameterized collections with generics. You can use generics to implement type-parameterized collections, but it doesn't really make sense to think of type-parameterized collections as a form of generics unless you can actually abstract over the type parameters (which you can't in Go).
Go does have generic collections, and generic functions operating on these collections.
> You cannot e.g. write a generic Go function to reverse an array.
You can if you're part of the core team and implement them as builtins. Go doesn't have userland generics, because users of Go are peons who can't be trusted with sharp implements.
> which you can't in Go
Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths.
Edit: we've had to ask you half a dozen times in the past not to post aggressively and uncivilly on HN. Would you please fix this? Reviewing the site guidelines should make it clear what we're looking for instead.
>Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths.
This can't really be the right explanation given that generics are now being added to the language. In any case, this kind of mean-spirited speculation about people's motives is borderline trolling, IMO. The Go team have publicly stated their reasons for not (initially) putting generics in the language. Unless you have some inside info suggesting that they're lying, I'd refrain from saying this kind of thing.
Go absolutely has this feature. Just not for you as a user of the language.
> It has some built-in operators that can operate on multiple types.
Go has multiple builtin functions which abstract over type parameters e.g. close() can operate on any chan, append() or copy() can operate on any slice. They are not operators (symbolic or keyword).
> Most languages have this. The arithmetic operators in C, for example, can take operands of many different types. This is not "generics".
It's overloading, +(int, int) and +(double, double) are separate functions under the same symbol. It's an orthogonal feature, so much so that there are plenty of languages which do have userland generics and don't have overloading.
> This can't really be the right explanation given that generics are now being added to the language.
The core team has been saying they're considering the feature / issue pretty much since the language was first released. You'll have to excuse me if I don't hold my breath.
It looks like you are in golang core team's minds. You appear to be able to judge intent. Impressive quality you have here.
Not at all, Rob Pike stated it fairly explicitly if in somewhat milder terms:
> The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
