IMO, because it's harder to break the rules. Sometimes the rules just need to be broken. There was a recent article about someone attempting to interface with OpenGL in Rust a month or so ago, and it discussed how they ended up giving up, since the things they needed to do didn't mesh well with how Rust expected programs to be written. If interfacing with a driver is so hard, how will interfacing with hardware be easier?
Programming for hardware requires a lot of breaking and bending the rules. How can being memory safe help when you're creating memory spaces as most software knows of it?
Performance is King, low memory overhead is Queen. Even rust can't take those thrones away from C. Not yet, at least. Perhaps not ever (I expect that C++ would have done it, were it possible for a language with the complexity of Rust).
> If interfacing with a driver is so hard, how will interfacing with
> hardware be easier?
It really depends. The key is to identify the proper ways to make the abstraction as safe as possible. This is a fairly new skill, in a new language. Said post was good, and the author has been using Rust for a long time, but one person failing to do so doesn't mean that it's impossible.I'm still a noob at this kind of thing myself, but I recently wrote a (tiny) driver for a memory-mapped device. My first iteration had tons of unsafe code. My second iteration had three lines of unsafe code. My latest iteration has zero unsafe code, though you do need one call to an unsafe function outside of it in order to construct it. (to create a slice from the raw memory location that's mapped.)
That is, of course, pretty much the simplest possible case. But I believe the pattern will hold, over time, as people learn how to do it.
> Even rust can't take those thrones away from C.
Rust is faster than C on some microbenchmarks. We'll see what the future holds.
For one, Rust is a different language from the other memory-safe languages that have existed in the past, and in fact incorporates a lot of research in programming languages that didn't exist when Ada was designed. But even if that weren't true, one thing that's changed since the past is we now are slowly understanding how difficult it is to write secure software in C, and how important it is to write secure software. When Unix was first designed we (the entire programming community) didn't know about a lot of security issues, and the lack of Internet meant that it was less important to defend against them. It is probably much more worth rewriting our tools in Ada today than it was ten or twenty or thirty years ago.