The Zen of Rust is very much in the direction that standard operators shouldn't be more "special" than necessary, and a lot of fundamentals become "library-able" or at least library-extensible. Go simply doesn't take this approach. It's a more opinionated language, and it some cases that means you get the tool it makes for you, rather than getting to craft your own tool for yourself.
The reason they exist is because Go language designers could not do without them. The same people that have claimed for years that Go didn't need generics.
Considering all the successful software that's been written in Go, they weren't exactly wrong.
Also, even if go were better than all other languages, it still might not be perfect.
Let’s say there are 10 ‘objectively good’ programming language features.
If most languages have 7, but go has 8, you still can complain about wanting the two other ones.
Considering all the successful software written in PHP...? Or Javascript...? Java...? Your argument absolutely has nothing to do with my point.
"Langues do not need function calls, successful software has been written in assembly" is a pretty weak argument.
https://medium.com/@arschles/go-experience-report-generics-i...
How much of that software doesn't use Go's internal generics?
It is such a lousy metric "if it is used it is good".
Well PHP and JavaScript are also used, a lot, even more than Go, most likely bringing home much more revenue as well.
I guess the new bit is the variable-arity result from a function, not just a language feature (e.g. <- or range).
Technically ("well, acksually"), Go doesn't "lack generics". It lacks user-defined generics. The language implementation has several generics in it, you just can't add your own. So if you hear "Go doesn't have generics" that can give you a slightly incorrect impression about the language itself, but of course what people do generally mean is that it lacks user-defined generics and that that is bad, so there's still certainly a valid criticism there. It just may not quite be what you thought it was.
If we call this type of ad-hoc implementation "generics", we're going down a very deep rabbit hole, since then almost any programming language can be said to have generics. For instance, Write[Ln] in Pascal, sizeof() in C, all array functions in Java pre-1.5. In other words, technically when people say "Language X lacks generics" they always mean "Language X lacks orthogonal, predictable, non ad-hoc, user defined generics".
So there's no point in requiring the "user-defined" qualifier. For "generics" to mean anything useful, there must be some languages that the word applies to and some that it doesn't. If you treat "user-defined" as implicit, then that works. If you don't, then it says nothing.
Yes it does, generics are types. You bet all these append(T[A],A)T[A] tricks are hard-coded in the compiler in an adhoc fashion, and not part of Go's type system.
https://github.com/golang/go/blob/3813edf26edb78620632dc9c7d...
My guess is they don’t have anything usable by the end user any way, otherwise they wouldn’t spend so much time thinking about a design for go 2. It probably means whatever is in the compiler isn’t that elegant, nor reusable.