Memory safety is still considered nice-to-have?

Posted Aug 20, 2024 9:47 UTC (Tue) by khim (subscriber, #9252)
In reply to: Memory safety is still considered nice-to-have? by jlarocco
Parent article: FreeBSD considers Rust in the base system

> I took "smart pointer" to mean std::shared_ptr, which is nothing like unique_ptr, and much more like Rust's borrow checker.

Nope. You either have no idea how Rust works or are mixing Rust and Swift.

Swift does automatic reference counting, Rust doesn't. Rust's references are much closer to std::unqiue_ptr than to anything else in a sense that Rust guarantees that when you are modifying something it's safe to do that: all other observers than may be affected by your changes are quiescent.

std::unqiue_ptr does more-or-less the same thing, but with a bad twist: if you are doing something wrong you are not getting a compile-time error, but runtime error — but only if you are lucky. That's why it's convenience feature and not a memory safety feature!

> If that's what they want to do good for them, but that doesn't mean they get to commit crap code.

Sure, but chances are high that if someone uses things they know and understand the end result would be better than if they would use something they don't, really, understand.

Situation with Rust is radically different: attempt to abuse something leads to compile time errors (there are certain soundness error where you can actually write code that compiler accepts and that is not correct, but it's very hard to hit these by accident… that's why Rust features are explicitly a safety features, but very explicitly not a security features, that's something else, again).