A case study on strict null checks
I&#x27;m a huge fan of strictNullChecks but it is remarkable how much language features contribute towards making non-nullable types ergonomic. For instance Rust has a lot of primitives on Option a lot nicer.<p>One that I love is `Option::ok_or` (or `Option::ok_or_else` if you like). It takes an Option and converts it to an error. With the try macro (?) it makes Option a lot easier to use. Compare:<p><pre><code>   function parseFile(file: File | null) {
     if (file === null) {
       throw new Error(&quot;File must exist&quot;);
     }
     &#x2F;&#x2F; TS now infers as File
   }
</code></pre>
to:<p><pre><code>   fn parse_file(file: Option&lt;File&gt;) {
      let file = file.ok_or(Error::new(&quot;File must exist&quot;))?;
   }
</code></pre>
Likewise if you want to apply a function to an Option if it is Some and pass along None otherwise, you can use `Option::map`:<p><pre><code>   fn parse_file(file: Option&lt;File&gt;) {
      let parse_result = file.map(|f| parse(f));
   }

</code></pre>
Indeed it&#x27;s a little interesting how libraries have adopted paradigms beyond the language. React is extremely expression based, but that makes for a clunky combo with JS&#x27; primarily statement based control flow. You see this in React developers&#x27; reliance on ternary operators and short circuiting for control flow in JSX.<p>Of course this just JavaScript being a classical imperative language. Not much to do about that.