Comment by vacuity
2 days ago
Don't mislead people like this. If you are writing C, oh well. If you are writing big unsafe Rust blocks, genuinely, you are holding it wrong. Rust's strength is that unsafe blocks are minimal and well-isolated, giving both the flexibility and performance of C and the assurances of safe Rust. The default is safe Rust and unsafe authors must ensure their code works when it is eventually contacted by safe Rust. That's why we can say Rust is memory-safe, like Java or C#, even though unsafe is a clearly advertised feature. Unsafe Rust is, at best, on par with C. Nice language features do not fix UB. If you're not taking advantage of safe Rust, you lose the benefits of using unsafe Rust. Rust's main innovation is the borrow checker; use it!
In the specific case where I'm using Rust, unsafe is definitely better. I mostly write eBPF XDP programs for where I write unsafe code.
So yes I agree that I don't get safety benefits. However, it does not mean I don't get increased reliability from it. Just type safety allows APIs to be expressed in ways you cannot hold them wrong. Heck, just getting a Result<u32, u32> instead of a i64 for faillible operations is a godsend.
In the end, this is why I'm a big proponent of Rust for many areas of programming, including areas where memory safety is the least of your concerns. My gRPC APIs are written in Rust, my system daemons are written in Rust, my eBPF probes are written in Rust. Rust is a modern language whose design is deliberate on many levels to address common issues in programming. If you'd ask me, Rust's "marketing" putting memory safety first is quite a disservice as there are many areas where it helps writing correct programs.
Greg KH noted this in his email in another branch of the thread, and I wholeheartedly agree with him.
> So yes I agree that I don't get safety benefits. However, it does not mean I don't get increased reliability from it. Just type safety allows APIs to be expressed in ways you cannot hold them wrong. Heck, just getting a Result<u32, u32> instead of a i64 for faillible operations is a godsend.
Generally, people talk about type system benefits and whatnot on top of safe languages. If you can't ensure safety, UB occurs and that goes out the window. I can't tell how you use unsafe in absolute terms, so I will just hope that you are saying you have an unusually high proportion of unsafe code but still manageable. Otherwise it invites the same "look over everything to make sure nothing can go wrong" practice as with C.
> In the end, this is why I'm a big proponent of Rust for many areas of programming, including areas where memory safety is the least of your concerns.
Memory safety should never be "the least of your concerns". The movement around memory-safe languages is because memory safety is the bedrock on which orthogonal concerns must be placed. Unsafe Rust is well and good because it is (hopefully) used sparingly and with great caution. It is the typical absence of unsafe Rust that characterizes its strengths. I agree that Rust has decent, if not strong, qualities for many other programming sectors, and many Rust critics do make an unreasonable amount of noise about memory safety and unsafe Rust, but Rust is what it is first and foremost because of its approach to memory safety, and everyone can agree to that. Your first comment undermines your stated desire to communicate that Rust should be seen as offering "memory safety plus more goodies".
I haven't written any eBPF programs, but I was under the impression that the eBPF subsystem rules and verifier take care of the "memory safety" aspect, at least to the program boundaries. Is that an incorrect understanding?
1 reply →