5 ms·

Why “Contracts” and not “Generics”? To make it less contentious, maybe, or to manage expectations?

• jsty 7y ago
  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."
  • iainmerrick 7y ago
    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.
    • jsty 7y ago
      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.
    • nemith 7y ago
      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) https://en.wikipedia.org/wiki/Concepts_(C%2B%2B) in constraining the generic type before template expansion.
      • pjmlp 7y ago
        Contracts in programming language have a very precise meaning. https://en.wikipedia.org/wiki/Design_by_contract https://en.wikipedia.org/wiki/Design_by_contract
• boomlinde 7y ago
  They’re not the same thing. Contracts are a means to define constraints for parameterized types.
• mhd 7y ago
  Maybe someone really wants to bother Bertrand Meyer.
• apta 7y ago
  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."
  • NateDad 7y ago
    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.
    • apta 7y ago
      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.
      • NateDad 7y ago
        ....in Go?
  • weego 7y ago
    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"
    • 7y ago
• jillesvangurp 7y ago
  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-contracts-f255ded41ef2 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.
• ychen306 7y ago
  The counterpart of "Contracts" in C++ is "Traits" not "generics".