If rust can do it so well, I see no remaining argument about performance and control. It was long believed that C++ had to be bad in this way because such languages must be. Rust was the counter example that ended this myth
One gap in my knowledge here is how well Rust can take advantage of per-architecture optimizations that can only be seen in the large.
One of the sources of complexity in the C++ I work with is that a lot of it is using templates to try to maximize the size of individual expressions. Consider, for example, the Eigen library (https://eigen.tuxfamily.org/index.php), which gains most of its magic in using compile-time template specialization to re-group logical operations so that the compiler can realize "Oh, this is really looping over dozens of memory cells to do the same operation... I should compile it using SSE instructions." I haven't seen yet whether / how Rust pulls off similar tricks or whether doing so in Rust requires a developer to write n-ary asm bindings, which would actually make Rust less expressive than C++ if the goal is maximizing performance with minimum code.
(Of course, the flip side of that is that there's a lot of Eigen that's unsafe behavior; hold the library slightly wrong, and you're operating on deallocated memory. Oops. ;) ).
That's not clear to me. The examples I've seen from anywhere that Rust has to deal with hardware suggest that you have to throw out most of the safety guarantees of the language, and this applies also to dealing with OS-provided abstractions of hardware (like MMU-mapped registers and mmap-ed memory regions).
I don't have the impression that Rust's container idioms match those of, say, Python, but I may just not know Rust well enough.
OK, let me put it differently: you cannot reason about safety in those circumstances in the way you can when "unsafe" has not been used. And since reasoning about safety (or perhaps more accurately, not needing to) is one of the raison d'etres for Rust, that's a bit of a hit. Not huge, but for those of us close to metal of some sort, it's a bit of a hit.
Yes, you can reason about safety in just the same way, as long as a safe API is built around the unsafe usage. That’s why you can have safe OpenGL bindings even though the underlying raw C calls are unsafe
Rust would be useless if you couldn’t have safety if you had any unsafe at any point. That’s the whole point of rust: you can build safe interfaces to unsafe actions
