[burntsushi]

> which is just annoying

I got that. I'm asking, why?

The decision to use generics or not has nothing to do with purity. It's about trade offs. If a decent balance can be struck with special privileged functions built into the language, I don't see how that is intrinsically bad.

[kenko]

It's not a decision about whether or not to use generics, it's a decision about whether or not to make it possible to use generics.

The developers have decided that they should make it possible for themselves to use generics, but impossible for you to use generics. Do you really not see why that's annoying? That's not a matter of tradeoffs, because they've already made generics possible---for themselves. At best they might be thinking something like "only WE are capable of grokking when generics are appropriate; everyone else would abuse them", which is rather arrogant, no? Lots of people have been saying that go is "missing" generics. The official response seems to be "no it isn't, you don't really need them." The unoffical response (evidenced by the use of generics in the compiler) is apparently "you're right, go is missing generics, so we'll include them, but just for ourselves".

[burntsushi]

> It's not a decision about whether or not to use generics, it's a decision about whether or not to make it possible to use generics.

Fine. That's what I meant.

> Do you really not see why that's annoying?

I can if you believe in purity over all else.

> That's not a matter of tradeoffs, because they've already made generics possible---for themselves.

Sorry, but what? Are you really trying to claim that adding generics for the entire language has exactly the same trade offs as adding a few built in functions that are generic?

> At best they might be thinking something like "only WE are capable of grokking when generics are appropriate; everyone else would abuse them", which is rather arrogant, no?

I think you've significantly misunderstood the issue. I believe my initial characterization is right: you think this is about purity. It's not.

Please read Russ Cox's short blurb on the "Generic Dilemma." [1] No part of it has anything to do with "we know better than you."

> The official response seems to be "no it isn't, you don't really need them."

No. The official response is "we don't know of an implementation that we're happy with." It's not a philosophical stance. It's a practical stance.

[1] - http://research.swtch.com/generic

[kenko]

Honestly, I don't know what you even mean by purity.

[burntsushi]

The context of this discussion started when people were complaining about the language designers being able to build in special functions that are type parametric. The implication was: if the language designers can do it, why won't they allow me to do it?

i.e., purity for purity's sake. It ignores legitimate trade offs between allowing a few special functions and building an entire generics system into the language.

[kenko]

I still don't know what you mean by "purity". Saying "i.e., purity" doesn't help, since I already knew that you think purity has something to do with generics being definable by people other than the language designers.

"If the language designers find it useful to occasionally use type-parametric functions, why won't they recognize that other people might also find it useful, too, and for other functions?" doesn't strike me as a demand for purity in any sense. Consistency, maybe; recognition that the designers are giving themselves special treatment, sure. What's pure about the desired state of affairs, or impure about the present?

Honestly, sometimes it seems as if someone who wants to defend Go against a criticism immediately claims that the critic is just obsessed with purity. Why else would you criticize Go?

[burntsushi]

This was the original comment that I responded to:

> and having the interpreter get special status in breaking them, see generics

It's a whine that the interpreter gets "special status." It's implicit in the complaint that special status is somehow bad. It ignores any trade offs that go into the design decision.

Purity in this context means: the language gets no extra special power that users of the language can't tap into themselves.

> Honestly, sometimes it seems as if someone who wants to defend Go against a criticism immediately claims that the critic is just obsessed with purity.

And sometimes it seems as if someone criticizes Go just because they are obsessed with stuffing as many features as possible into a programming language. Shit happens.