That's something for the Go creators to decide, but personally I enjoy the feeling of safety that comes with lack of generics. I have very few Go bugs at runtime and I think that explicitness plays a huge part in it.
func (a ByAge) Len() int { return len(a) }
func (a ByAge) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
func (a ByAge) Less(i, j int) bool { return a[i].Age < a[j].Age }
And not having generics means that (as far as I can tell) people end up using a lot of `interface{}`. How does that increase safety?
More importantly, why would I want to use a language whose solution to the problem of "dealing with generic data" essentially boils down to "use a void*"?
There are too many indirections to follow manually. All I know is that the compiler will select some function that has conforming types. The compiler is very very smart. It knows all the incredibly complicated name resolution rules and it will use each one of them.
Unfortuntately I'm not as smart. Even after more than 20 years of using C++ I sometimes fail to anticipate which function the compiler decides to use. And that is not safe.
In fact it is less safe than casting interface{}, because that will at least fail fast at runtime instead of silently doing something unexpected.
I think Go needs some form of generics. Every statically typed language does. But after C++ I do understand the hesitation on the part of Go's creators.