Are unsound type systems wrong?
I&#x27;ve worked a lot with TypeScript after a background in more type-y languages like O&#x27;Caml and Haskell and have eventually gained a real appreciation for the engineering tradeoff they made.  This article sorta frames soundness like it&#x27;s a feature -- one could have soundness or not, so why not have it -- when in really a specific technical term about a property of a language that programmers often don&#x27;t understand (as evidenced by the other comments on here) and which has specific consequences.<p>Instead, I now view type systems as a tool that can make tradeoffs to get the job done, in the same space as &quot;IDE&quot; or &quot;test-driven design&quot;.  With those it&#x27;s easy to make statements about the specific programmer tradeoffs, such as &quot;test-driven design means you spend more time writing tests but gives you more confidence about the results&quot;.  With a given type system, you can evaluate it like &quot;type system X lets you get autocomplete in your editor&quot;, or &quot;type system Y catches the common error of Z&quot;.<p>Meanwhile if you only focus on soundness you end up with counterintuitive results like where Java is sound but still has NullPointerExceptions everywhere, or languages like Rust where whole data structures and algorithms are disallowed because you can&#x27;t express their correctness to the compiler.  (To be clear I appreciate exactly why Rust must do this, but again you can evaluate that tradeoff as &quot;preserves memory safety without GC, disallows doubly-linked lists&quot; rather than &quot;is the type system &#x27;correct&#x27;&quot;.)<p>One view that really opened my eyes on this Gilad Bracha&#x27;s talk on pluggable and optional type systems: <a href="http:&#x2F;&#x2F;lambda-the-ultimate.org&#x2F;node&#x2F;1311" rel="nofollow">http:&#x2F;&#x2F;lambda-the-ultimate.org&#x2F;node&#x2F;1311</a> .