zlacker

It's really common to see people say meaningless stuff like "Rust is a safe language" which is either deeply confused or deeply misleading.

Rust provides certain guarantees of memory safety, which is great, but it's important to understand exactly what that means and not to oversell it.

>>TillE+(OP)
It's an unproductive pedantry to expect every mention of the generalisation to be followed by a full disclaimer about exceptions and edge cases.

People say "it's raining" without having to add "except under roofs".

>>pornel+g2
I think, if the wording was exactly "Rust is safe" it is indeed too vague as there are many notions of safety, and annoyingly enough people do say this. But "Rust provides memory safety" is clear enough and doesn't need further quantification.

>>pornel+g2
Think of it as elaborating, rather than disclaiming. There is a real problem in the realm of Rust advocacy where people make a blanket claim, either wrongfully assuming it is true or assuming that others are aware of the limitations of the claim. This is a problem when the reader is not aware of the limits of what is being said, while creating conflict when the reader calls out the limitations.

Reading a book on Rust programming is an entirely different matter since authors tend to elaborate upon what they are claiming. The reader has to understand how things work and what the limits are. As such, there is less opportunity for misinformation to spread and less room for conflict.

>>lifthr+p6
Official Rust materials are careful not to overpromise and to be clear on the extent of what is guaranteed and what isn't.

The safety is always with an asterisk. Rust provides memory safety — provided that unsafe blocks, FFI, and other code running in the same process, and the OS itself, and the hardware doesn't misbehave.

But if you accept that Python and Java can be called safe languages then Rust can be too. The other ones also have unsafe escape hatches and depend on their underlying implementations to be correct to uphold safety for their safe side.

>>pornel+98
All this safety, as Linus points out, is safety for plain programs, but a complex of serious problem for the kernel. "Safe languages" are only safe up to a point and in context; Rust has clearly been designed to write safe applications, not safe kernels.

So if some enthusiasts are trying to use Rust at cross purposes for Linux they are likely to appear obnoxious and entitled, and it is perfectly right to challenge them to prove that they can make Rust suitable.

There's more high quality and polite preaching earlier in the thread, for example:

  > Please just accept this, and really *internalize* it.  Because this isn't actually just about allocators. Allocators may be one very common special case of this kind of issue, and they come up quite often as a result, but this whole "your code needs to *understand* the special restrictions that the kernel is under" is something that is quite fundamental in general.

>>pornel+g2
Except everyone understands it's not raining under roofs. When someone says 'Rust is safe', they assume it infallible. It's been oversold.

>>pornel+g2
This is the patronizing attitude that keeps getting Rust advocates into trouble. "I don't need to be pedantic, I know better than you, so I'll just simplify my argument down to the point that it's actually a lie, but you'll thank me later"