“Rust is safe” is not some kind of absolute guarantee of code safety
As usual HN comments react to the headline, without reading the content.<p>A lot of modern userspace code, including Rust code in the standard library, thinks that invariant failures (AKA &quot;programmer errors&quot;) should cause some sort of assertion failure or crash (Rust or Go `panic`, C&#x2F;C++ `assert`, etc). In the kernel, claims Linus, failing loudly is worse than trying to keep going because failing would also kill the failure reporting mechanisms.<p>He advocates for a sort of soft-failure, where the code tells you you&#x27;re entering unknown territory and then goes ahead and does whatever. Maybe it crashes later, maybe it returns the wrong answer, who knows, the only thing it won&#x27;t do is halt the kernel at the point the error was detected.<p>Think of the following Rust API for an array, which needs to be able to handle the case of a user reading an index outside its bounds:<p><pre><code>  struct Array&lt;T&gt; { ... }
  impl&lt;T&gt; Array&lt;T&gt; {
    fn len(&amp;self) -&gt; usize;

    &#x2F;&#x2F; if idx &gt;= len, panic
    fn get_or_panic(&amp;self, idx: usize) -&gt; T;

    &#x2F;&#x2F; if idx &gt;= len, return None
    fn get_or_none(&amp;self, idx: usize) -&gt; Option&lt;T&gt;;

    &#x2F;&#x2F; if idx &gt;= len, print a stack trace and return
    &#x2F;&#x2F; who knows what
    unsafe fn get_or_undefined(&amp;self, idx: usize) -&gt; T;
  }
</code></pre>
The first two are safe by the Rust definition, because they can&#x27;t cause memory-unsafe behavior. The second two are safe by the Linus&#x2F;Linux definition, because they won&#x27;t cause a kernel panic. If you have to choose between #1 and #3, Linus is putting his foot down and saying that the kernel&#x27;s answer is #3.