Linus may view his job as "Saying No" but the way he does it still leaves a little to be desired, because his reasoning is sound here, but it's less "Follow my reasoning" than "You don't want to get yelled at again do you?"
[0]: https://lore.kernel.org/lkml/CAFRnB2VPpLSMqQwFPEjZhde8+-c6LL...
>>>> No (Linus)
>>> As you know, we're trying to guarantee the absence of undefined behaviour for code written in Rust. And the context is _really_ important, so important that leaving it up to comments isn't enough.
…
>>> Do you have an opinion on the above?
>> This message. Ie. No. you can’t make everyone play by your rules. (Linus, grumpily)
> While I disagree with some of what you write, the point is taken.
> But I won't give up on Rust guarantees just yet, I'll try to find ergonomic ways to enforce them at compile time.
I mean, it doesn’t sound like he’s being petty or misunderstanding.
They want special rules (which won’t work) to do runtime checking for rust code. That seems weird, right?
Rust safety should be compile time. That’s the point…
I dunno, maybe I don’t understand what’s being said, but I don’t think Linus is particularly wrong here, even if it’s kind of shouty.
Array bounds checks are one of the most important safety measures Rust takes, and those have to happen at runtime (if the optimizer can't prove they'll never fire). Similarly, locking types like `Mutex` of course do all their locking and unlocking at runtime, though they also use the type system to express the fact that they will do that.