zlacker

>>rvz+(OP)
I know next to nothing about kernel programming, but I'm not sure here what Linus' objection to the comment he is responding to here is.

The comment seemed to be making reference to rust's safety guarantees about undefined behaviour like use after free.

Linus' seems to have a completely different definition of "safey" that conflates allocation failures, indexing out of bounds, and division by zero with memory safety. Rust makes no claims about those problems, and the comment clearly refers to undefined behaviour. Obviously, those other problems are real problems, but just not ones that Rust claims to solve.

Edit: Reading the chain further along, it increasingly feels like Linus is aruging against a strawman.

>>a_hume+h4
From a quick skim, it seems to me that at least in Linus's interpretation, his interlocutor is requesting changes to the way the kernel does things in order to accommodate/maintain Rust's "there is no undefined behaviour; in cases where circumstances conspire to make behaviour undefined, terminate immediately" philosophy even in kernel Rust code. He then figures that if he said he is not willing to do that, the other side would respond with something to the effect of "but implementing the Rust philosophy in full means you get safety, and you surely can't have a goal more important than that", and therefore leaps to talking down the importance of the safety that Rust actually guarantees, to argue that it is not actually so great that all other objectives would be secondary to it.

If his initial interpretation and expectation of the Rustacean response is in fact correct, the line of argumentation does not seem per se wrong, but I do think that it is bad practice in adversarial conversations to do the thing where you silently skip forward several steps in the argument and respond to what you expect (their response to your response)^n to be instead of the immediate argument at hand.