Probably because they don't want people talking cross-purposes or confusing their proposals with what is implemented in other languages, as they call out in the intro:

"As the term generic is widely used in the Go community, we will use it below as a shorthand to mean a function or type that takes type parameters. Don't confuse the term generic as used in this design with the same term in other languages like C++, C#, Java, or Rust; they have similarities but are not the same."

Those four languages all have completely different implementations of parameterized types, but calling them all “generics” doesn’t add any extra confusion.

To the contrary, it’s actually helpful to use the same word for something with roughly the same uses (eg generic type-safe container classes) even if the details are very different.

Contract is just the feature is defines the abilities of the genericized types.

A contract in Go enables generic programming or as other state it "generics".

In C++20 there is concepts which is very similar. https://en.wikipedia.org/wiki/Concepts_(C%2B%2B) in constraining the generic type before template expansion.

Contracts in programming language have a very precise meaning.

https://en.wikipedia.org/wiki/Design_by_contract

I don't particularly disagree. My point was more that given what the authors wrote in the quoted sentence, I thought that - rightly or wrongly - was likely the reasoning behind the naming decision.

Indeed, this could end up being confusing. Kotlin is adding a feature to the language with the same name (https://blog.kotlin-academy.com/understanding-kotlin-contrac...) and it has nothing to do with Generics. Kotlin contracts allow functions to be annotated with information about e.g. the nullability, the type, or the amount of times a thing will be called. The compiler can then use this to infer that code that otherwise would not have compiled is actually safe without that check. The main use case seems to be smart casts of nullable types to non nullable or of abstract types to concrete types.

Go uses curly braces. Lots of similarly braced languages (Java, Kotlin, Scala, Typescript, ...) have generics and type parameters. Maybe generics is not a bad name for this.

Maybe someone really wants to bother Bertrand Meyer.

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.

....in Go?

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.

Searching “trait bounded generics” reveals nothing generic. Only rust results.

Did you mean ad-hoc polymorphism?

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.

They’re not the same thing. Contracts are a means to define constraints for parameterized types.

The counterpart of "Contracts" in C++ is "Traits" not "generics".