3 ms·
There are different algorithms for type checking that impose different requirements on users. The Java approach is roughly: write types everywhere, keep them s
by danpalmer 3y ago
There are different algorithms for type checking that impose different requirements on users.
The Java approach is roughly: write types everywhere, keep them simple (and limited in scope), it's easy for the compiler to infer the types.
The Haskell/ML approach is roughly: know a lot about strong type systems, be purely functional, infer most of the types, produce bad error messages when you can't.
The Swift approach attempts to be the best of both worlds, lots of inference, strong capabilities in expressing complex types, but the trade-off is that it can't use the inference algorithms of either of the above examples. I believe Swift necessarily has poor time complexity in type checking – it can't be better with the design it has and requirements it puts on authors.
- kaba0 3y agoRust’s type system seems to be ideal in this respect, and is not prone to timing out, so it is likely some design issue with Swift.
- danpalmer 3y agoOn the contrary, Rust's type system moves more of that effort on to the developer – there's a reason why Rust has a much steeper learning curve than Swift. The trade-off is a somewhat rare sharp edge for Swift and a much easier onboarding, vs Rusts noticeably harder onboarding and more predictable sharp edges.
- kaba0 3y agoRust is a low-level language, which requires the dev to track lifetimes as well - that’s the reason it has harder onboarding. It managing an even more complex type system without any of the disadvantages seems to make it clearly great!