“Rust is safe” is not some kind of absolute guarantee of code safety
&gt; Even &quot;safe&quot; rust code in user space will do things like panic when
things go wrong (overflows, allocation failures, etc). If you don&#x27;t
realize that that is NOT some kind of true safely[sic], I don&#x27;t know what
to say.<p>&gt; Not completing the operation at all, is <i>not</i> really any better than
getting the wrong answer, it&#x27;s only more debuggable.<p>What Linus is saying is 100% right of course - he is trying to set the expectations straight in saying that just because you replaced C code with multi thousands (or whatever huge number) of man months of efforts, corrections and refinements with Rust code it doesn&#x27;t mean absolute safety is guaranteed. For him as a kernel guy just as when you double free the kernel C code detects it and warns about it Rust will panic abort on overflows&#x2F;alloc fails etc. To the kernel that is not safety at all - as he points out it is only more debuggable.<p>He is allowing Rust in the kernel so he understands the fact that Rust allows you to shoot yourself in the foot a lot less than standard C - he is merely pointing out the reality that in kernel space or even user space that does not equate to absolute total <i>safety</i>. And as a chief kernel maintainer he is well within his rights to set the expectation straight that tomorrow&#x27;s kernel-rust programmers write code with this point in mind.<p>(IOW as an example he doesn&#x27;t want to see patches in Rust code that ignore kernel realities for Rust&#x27;s magical safety guarantee - directly or indirectly allocating large chunks of memory may always fail in the kernel and would need to be accounted for even in Rust code.)