undefined | Better HN

0 pointswudangmonk3y ago0 comments

You can have a good type system and have fast compile times. In every single language with 'complicated type systems' it always comes down to type inference on polymorphic types which causes these issues, this has been known for over 40 years yet the same issue seems to be rediscovered again and again like it was something new.

I sure hope the author learned the right lesson from the failure that is Swift and Mojo turns out to be better. I do not want a language with a complicated type system and long compile times. I want a 'good enough' type system and fast compile times.

0 comments

3 comments · 1 top-level

aw16211073y ago· 2 in thread

> it always comes down to type inference on polymorphic types which causes these issues

Unless I'm thinking of something different, doesn't OCaml have type inference on polymorphic types and fast(ish?) compile times?

I was under the impression that the breakdown of causes for Rust projects compiling slowly is very project-dependent as well. From what I can remember common culprits were monomorphization and/or LLVM, though I'm not sure if that has changed recently.

octachron3y ago

Fast (and principled) inference for not-too-complicated polymorphic types is an explicit design goal for OCaml and Haskell languages. And this design goal constraint quite a lot the type system.

Typically, there are many type system features that break this property and where OCaml and Haskell requires type annotations (for instance polymorphic functions that takes polymorphic functions as arguments and use them in a polymorphic way).

As a consequence, typechecking for OCaml programs tend to take from 10% to 60% of the whole compilation time for typical programs. However, for OCaml programs that make heavy use of GADTs typechecking can dominate the compilation time (probably due to the exhaustiveness check but I have yet to empirically check that).

Infamously, Swift made the choice to introduce a typechecking algorithm with an exponential complexity in the size of expression (to support function overloading and literals) even for simple types.

aw16211073y ago

Fascinating! Thanks for the insight!

Does the up to 60% figure include programs that make heavy use of GADTs, or are those even worse in terms of the proportion of compilation time spent type checking?

I had no idea Swift's type checking algorithm is exponential. How easy is it to run into those conditions?

1 more reply

j / k navigate · click thread line to collapse