> 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.