Conversation

The main downside of generics is that once your language has them, you will spend the majority of your time going forward working on the generics implementation
4
55
IME this is only true insofar as your language does type-directed dispatch or derivation, or has subtyping and variance issues. If your generics are unrefined and unrelated universals/existentials, you can mostly just implement them once and move on.
2
12
Problem is, without these things in your type system, you'll spend the majority of your time on the module system or ad-hoc other type system features instead, if ocaml is any indication
2
Maybe. I think it's also possible that different factorings of concerns can have different incidental complexity, and am not certain "encode everything as higher-order pattern unification problems in the generic matching algorithm" is the global minimum.
2
1
(_Especially_ not when it's intertwined with more than zero orthogonal overload-resolution systems. C++ and Swift did not dodge this bullet; Rust very narrowly did, thank goodness...)
1
2
With all the specialization and overlapping-instance stuff getting added to Rust it looks like the bullet may still be in transit
2
1
I definitely believe Gilad Was Right about making it so nothing in your language *requires* the type system to resolve
1
3
Yeah, at least this I think I agree with: I'd prefer the boundary be such that the system can decide which programs run (i.e. which functions are called) without any type judgements. But that paints a _lot_ of the contemporary design space out.
1
1