2 ms·

I think we’re on the same page here. Neither of us agree with a blanket assertion that code written in Rust is flawless and free of bugs. This can be easily d

I think we’re on the same page here. Neither of us agree with a blanket assertion that code written in Rust is flawless and free of bugs. This can be easily disproved by looking at the bugs fixed in the Rust compiler and standard library, and looking at open soundness issues in the Rust issue tracker. I think CVEs are useful in tracking the security of your code, but can’t be meaningfully compared between languages. Different languages and ecosystems have differing bars on what needs a CVE. The important takeaway is that while Rust and Rust code in general aren’t perfect, they’re still substantially better than the alternatives. Better is hard concept to convey and get people to buy into. They see a couple of bugs and say “well, there’s bugs either way so what difference does it make”.

kprotty 4y ago
Yea, I think we're mostly on the same page. For higher level domains where unsafe isn't required and some runtime overhead is acceptable, I believe there's real cases to be made that Rust can be substantially better than the alternatives; Can prevent logical UAF with borrowing, bound checks may be mostly elided, enforced language level checks for nullability like Option<&T> and valid values in general like enums, explicit error handling, etc. For lower level domains however, I'm not sure that argument is as easy. Anecdotally, I work almost exclusively on systems like databases, schedulers, allocators, and similar. There, memory efficiency is an explicit feature via tricks that either Rust's borrow checker really doesn't like or are very awkward to do with its unsafe APIs; Non-linear/concurrent object lifetimes, self-referential & intrusive data structures, and reinterpret casting being the big ones. If rust code makes it harder to do those things, while also providing little (never none) benefit over the alternatives (for reference, both Zig & Rust have checked {integer ops, slice access, nullability}, sum types, metaprogramming, rich error combinators, etc.) then it's harder to make the claim Rust is substantially better.
- nindalf 4y ago
  I can't speak about the experience of writing unsafe. I haven't written any, and hope never to do so. That said, your concerns are pretty valid, widely echoed and are being taken seriously. Writing unsafe code is a chore and it needn't be. I'm hoping the newly created Operational Semantics team (https://www.rust-lang.org/governance/teams/lang#Operational%20Semantics%20team https://www.rust-lang.org/governance/teams/lang#Operational%...) makes progress here.

kprotty 4y ago

Yea, I think we're mostly on the same page. For higher level domains where unsafe isn't required and some runtime overhead is acceptable, I believe there's real cases to be made that Rust can be substantially better than the alternatives; Can prevent logical UAF with borrowing, bound checks may be mostly elided, enforced language level checks for nullability like Option<&T> and valid values in general like enums, explicit error handling, etc. For lower level domains however, I'm not sure that argument is as easy. Anecdotally, I work almost exclusively on systems like databases, schedulers, allocators, and similar. There, memory efficiency is an explicit feature via tricks that either Rust's borrow checker really doesn't like or are very awkward to do with its unsafe APIs; Non-linear/concurrent object lifetimes, self-referential & intrusive data structures, and reinterpret casting being the big ones. If rust code makes it harder to do those things, while also providing little (never none) benefit over the alternatives (for reference, both Zig & Rust have checked {integer ops, slice access, nullability}, sum types, metaprogramming, rich error combinators, etc.) then it's harder to make the claim Rust is substantially better.

nindalf 4y ago
I can't speak about the experience of writing unsafe. I haven't written any, and hope never to do so. That said, your concerns are pretty valid, widely echoed and are being taken seriously. Writing unsafe code is a chore and it needn't be. I'm hoping the newly created Operational Semantics team (https://www.rust-lang.org/governance/teams/lang#Operational%20Semantics%20team https://www.rust-lang.org/governance/teams/lang#Operational%...) makes progress here.