> Or, put another way, why specifically do you think it didn't happen with previous memory-safe languages?
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.
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).