3 ms·

I think the Vec example makes the opposite argument from the one you put forth. Vec uses unsafe internally in order to have the desiref API and performance char

I think the Vec example makes the opposite argument from the one you put forth. Vec uses unsafe internally in order to have the desiref API and performance characteristics, but it exposes a safe API. If there are bugs in the unsafe blocks that can cause UB all over the place, but it also makes it easier to audit. > There is just no way to avoid it and do something useful at the same time. I don't think that's true. Your code might have to rely on code down the abstraction layers that uses unsafe, as interacting with the hardware is inhere you unsafe, but that doesn't mean that any code you want to write won't be able to leverage the safe abstractions. The argument you're making sounds to me, and please correct me if I'm misunderstanding, that trying to create safe abstractions is sheer folly so we might as well not do so. I've been writing Rust code for years now and I've never had to write unsafe code myself other than when interacting with C code and when doing so I've found issues with the way the API the C libraries were exposing having fundamental issues.

dahfizz 6y ago
> Your code might have to rely on code down the abstraction layers that uses unsafe, as interacting with the hardware is inhere you unsafe, but that doesn't mean that any code you want to write won't be able to leverage the safe abstractions. This is the point I was trying to make by linking to the vec code. Any useful Rust program will run unsafe code. That code might just be hidden in a library. Ultimately, you are trusting that the code author did not write any bugs - in this regard you are not much safer than using the C++ stl. > The argument you're making sounds to me, and please correct me if I'm misunderstanding, that trying to create safe abstractions is sheer folly so we might as well not do so. On the contrary! I think what Rust is doing is a big step forward. But it is very important to keep in mind the limitations of a system. The authors attitude of "This is written in Rust, so it must be free of memory bugs!" is dangerous. The key benefit of Rust is to isolate and explicate the dangerous parts of your program (because there are dangerous parts!!). This should make you more vigilant of bugs, but the "Eh, the borrow checker will debug for me" attitude can often lead to programmers being less critical of their own code. Of course, none of this really applies if you are doing higher level stuff. But QEMU would definitely have to write their own 'unsafe' code.
- tedmielczarek 6y ago
  Here's the thing these arguments always miss: writing C/C++ is like writing your entire Rust program using unsafe. Sure, unsafe Rust code will always exist and can cause memory safety bugs. It's a lot easier to verify a few unsafe blocks in a Rust program than it is to keep all of your C++ program's invariants in your head and manually make sure you don't violate them.

dahfizz 6y ago

> Your code might have to rely on code down the abstraction layers that uses unsafe, as interacting with the hardware is inhere you unsafe, but that doesn't mean that any code you want to write won't be able to leverage the safe abstractions. This is the point I was trying to make by linking to the vec code. Any useful Rust program will run unsafe code. That code might just be hidden in a library. Ultimately, you are trusting that the code author did not write any bugs - in this regard you are not much safer than using the C++ stl. > The argument you're making sounds to me, and please correct me if I'm misunderstanding, that trying to create safe abstractions is sheer folly so we might as well not do so. On the contrary! I think what Rust is doing is a big step forward. But it is very important to keep in mind the limitations of a system. The authors attitude of "This is written in Rust, so it must be free of memory bugs!" is dangerous. The key benefit of Rust is to isolate and explicate the dangerous parts of your program (because there are dangerous parts!!). This should make you more vigilant of bugs, but the "Eh, the borrow checker will debug for me" attitude can often lead to programmers being less critical of their own code. Of course, none of this really applies if you are doing higher level stuff. But QEMU would definitely have to write their own 'unsafe' code.

tedmielczarek 6y ago
Here's the thing these arguments always miss: writing C/C++ is like writing your entire Rust program using unsafe. Sure, unsafe Rust code will always exist and can cause memory safety bugs. It's a lot easier to verify a few unsafe blocks in a Rust program than it is to keep all of your C++ program's invariants in your head and manually make sure you don't violate them.