“A serious take on a contract-based language“ Not ambitious enough. We already have dependent type systems and what I will call “property based types” since I

“A serious take on a contract-based language“ Not ambitious enough. We already have dependent type systems and what I will call “property based types” since I forget the proper name e.g. https://ucsd-progsys.github.io/liquidhaskell-blog/ https://ucsd-progsys.github.io/liquidhaskell-blog/. The compiler can check anything from silly out of bounds conditions to more complex assertions. Even without that, a good type system will allow you to alias types but have a constructor do a check. Once you use the Percentage0_100 type you know that it must be in that range, and the method doesn’t need to check it again. In think Haskell is “too much” for a lot of teams, but sprinkling in some compile time assertions and making that ergonomic with linting and so on would be a boon on par with async/await. “Unit test?” no need, I have a proof!