[catnaroek]

> By ensuring that developers and architects conform to certain conventions

Enforcing conventions is of course a good thing! The problem is how Go enforces conventions:

(0) When Go enforces a convention mechanically, it's a triviality that can be adequately handled by external tools (e.g., naming, formatting, unused variables, etc.).

(1) When a convention is actually useful (e.g., the correct way of using an interface), Go's type system is too dumb to understand it, let alone enforce it.

> aren't performant enough for new features

Second-class parametric polymorphism (“generics”) is purely a compile-time feature. It can be completely eliminated (that is, turned into the non-generic code you would've written otherwise) using a program transformation called “monomorphization”, before any target machine code is generated. So there's no runtime price to be paid.

[chrismonsanto]

To be precise, you need to outlaw polymorphic recursion to be able to do full monomorphisation. I'm not sure if that's what you meant by "second-class" in this context

[catnaroek]

First-class polymorphism is what System F gives you: functions from types to values.

Second-class polymorphism is what Damas-Milner gives you: let-bound identifiers may admit more than one type, in which case every type they admit is subsumed by a type schema.

Second-class polymorphism rules out polymorphic recursion if you consider every recursive definition as syntactic sugar for applying a fixed point combinator to some expression of type `a -> a`, for whatever monotype `a`.

[chrismonsanto]

That's a new turn of the phrase for me. I've only ever heard the expression "second-class parametric polymorphism" used in reference to enforcing predicativity (which does not rule out polymorphic recursion)

[catnaroek]

Ah, I might be wrong, then. Pretend I said “let” instead of “second-class”.