Russ Cox said this year that generics aren't left out because of political reasons or design choice.
They've been saying that from the begining. There are no real technical constraints, it's been done in all kinds of languages and it has been a well understood feature for 2+ decades. They just don't want to do the compromises needed, while letting the developers continue to deal with all of them...
They've been solved for many other languages but not for Go.
The lessons learned don't necessarily translate well between languages, because different problems need to be solved. Each language is a bag of features that need to work well with all the other features included in the language.
Do you find Go imposing any special set of contraints? If anything is far less featureful and Algol-like than most of the other languages that have found a way to fit Generics.
As far as I know it's not that something couldn't be shoehorned in, but rather that the language designers' tastes result in additional technical constraints.
Apparently they don't want to support only boxed types (like Java), and they also don't want to generate multiple implementations of each generic function for each size, resulting in code bloat (like C++), or to generate code at runtime (like, say, Julia).
You could argue that they should just make a choice and go with it because generics are so important, and some language designers would do that, but then these differences in design goals are why we have different languages in the first place.
This is based on an early article by Russ Cox [1]; I don't know how the teams' position has evolved since then.
Go does have some things like interfaces that don't work quite like they do in other languages.
I have yet to see a full technical proposal that integrates well with the existing language features and has no nasty corner cases. If such a thing existed, I'd be among the first to stand up and applaud it.
The best solution currently (IMHO), is code generation with things like gen [1]. Though I have yet to use that in a real project, so I can't say for sure it is actually the best solution.
Comments
They've been saying that from the begining. There are no real technical constraints, it's been done in all kinds of languages and it has been a well understood feature for 2+ decades. They just don't want to do the compromises needed, while letting the developers continue to deal with all of them...
See also pcwalton's (of Rust fame) comment below.
They've been solved for many other languages but not for Go.
The lessons learned don't necessarily translate well between languages, because different problems need to be solved. Each language is a bag of features that need to work well with all the other features included in the language.
Do you find Go imposing any special set of contraints? If anything is far less featureful and Algol-like than most of the other languages that have found a way to fit Generics.
As far as I know it's not that something couldn't be shoehorned in, but rather that the language designers' tastes result in additional technical constraints.
Apparently they don't want to support only boxed types (like Java), and they also don't want to generate multiple implementations of each generic function for each size, resulting in code bloat (like C++), or to generate code at runtime (like, say, Julia).
You could argue that they should just make a choice and go with it because generics are so important, and some language designers would do that, but then these differences in design goals are why we have different languages in the first place.
This is based on an early article by Russ Cox [1]; I don't know how the teams' position has evolved since then.
[1] http://research.swtch.com/generic
Go does have some things like interfaces that don't work quite like they do in other languages.
I have yet to see a full technical proposal that integrates well with the existing language features and has no nasty corner cases. If such a thing existed, I'd be among the first to stand up and applaud it.
The best solution currently (IMHO), is code generation with things like gen [1]. Though I have yet to use that in a real project, so I can't say for sure it is actually the best solution.
[1] https://clipperhouse.github.io/gen/