[Daishiman]

This is my own personal opinion on core dev's position and no one else's, but to me generics and dependency management have always been the pink elephant in the room.

I can wait for features; I'm patient. But the downright refusal of Go's core team to even begin to address this issue is not just a technical problem, but a communications one. This is clearly big for a lot of people, and I have yet to see any serious responses aside from either "you domain model's wrong if you need generics" or "deal with it".

In contrast (just picking this language for its community outreach, not because of any perceived technical competition), Rust's core devs have been forthcoming about practically every objection they've gotten. Their answers are clear, detailed, not demeaning, and constructive. When they don't know, they're honest about it, and when answers are hard, they take the time to explain. But I have never heard of anyone being belittled for not understanding lifetimes or the borrow checker.

Yet it seems that somehow if I have a bone to pick with Go not being able to dispatch functions by argument or arity, or with how its simplicity ends up with codebases a lot of people would consider much more verbose than necessary, it's just that I don't "get it". The problem isn't even in the accusation; I just don't even receive examples or reasonable explanations, something I'm used to in related language discussions.

I was willing to give the language a pass on these things when it was just getting started and a lot of the classical, early product criticisms were abound. But it's gotten tiring; the number of unanswered questions is remarkable by now.

[ngrilly]

If you haven't found any "serious response", maybe it's because you haven't searched enough.

Here is a "clear, detailed, not demeaning, and constructive" answer of Ian Lance Taylor that addresses your concerns:

https://groups.google.com/d/msg/golang-nuts/smT_0BhHfBs/MWwG...

I would guess his answer will not suit you, but you can hardly argue the Go team ignores the issue or refuses to talk about it.

[crawshaw]

Several members of the Go team have put a lot of time into studying and prototyping various implementations of generics.

If you look through the mailing list archives you will find many emails from Ian Lance Taylor on the topic.

[Daishiman]

I'll be completely honest: it's one of the most BS reasons I've ever read in a technical discussion.

How can we talk about high performance when:

* The current "generics" mechanism (interface et al) does runtime introspection, which is just about as slow and unwieldy as it gets * There is no option for pervasive, truly high-performance data structures since everything is a map (which comes with its own type parametrization as an exception to everything else), and if you don't like the hashing algorithm, tough luck. * You have a garbage collector running in the background, which is barely tunable compared to the options other runtimes have

Talking about performance when it's convenient as an argument against generics but disregarding the other holes in the language is not reasonable, because I would say that the choice of implementation for native maps is probably far more important for high performance. Yet here we are, no one complaining.

So we can really discard the performance argument, thus there is now an ample, valid set of choices for generic programming, several of which don't go against the goals of fast compilation.

Speaking of fast compilation; pretty much everything is going to be faster than C++ templates, since the entire compilation chain in C++ is slow.

[crawshaw]

It would be unreasonable to have designed a generics implementation into Go 1 that did not cover the builtin polymorphic map, slice, and append. A simple set of orthogonal features is an important principle in Go.

For these, performance is most certainly critical.