golang likes to reinvent the wheel and call it something else. We've already seen it with exceptions (which they called "panics"). Contracts already mean something else (see contracts in C++, C#, D, etc.).
What they're proposing here are basically trait bounded generics. They just don't want to use the word "generics" because of the following attitude:
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
Man you Go haters LOOOVE to trot out that quote from 2014.
But you know what, go is easy to learn, and that's been awesome in my experience. I can (and have) hired people who have never written go, and they're productive in a week or two.
That's not really a good metric to target. They can be productive in a week, and because the language is very weak and verbose, you'll end up with a messy code base. I see this all the time at an employer.
I think that's an unfortunate way to see it. Ignoring the possible resilience to using more recognised naming conventions and having gone around the houses in languages for good and bad I'd go more along the lines of "software engineering is hard, the tools to do it well don't need to be"
Reality is complex, and having weak tools and languages just pushes complexity further down the line. It's quite evident of the extremely verbose, messy code bases that come out of using golang in even slightly complex domains.
The vast majority of the claims behind golang (e.g. "large scale development", etc.) are not only baseless, but practical review of golang code bases shows that it's actually a step backward, and those claims do not manifest.
See how Rust or C# do generics, as well as Java or Scala (I think this feature is also called "Concepts" in C++, but I'm not sure it supports it yet).
You specify a type parameter, and then statically write out that it has to adhere to a certain interface/trait. This analysis is done at compile time, not runtime as with virtual dispatch.
What they're proposing here are basically trait bounded generics. They just don't want to use the word "generics" because of the following attitude:
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."