C++ has had many benefits over C for embedded s/w for many years and has similarly failed. Note that contrary to popular belief, C++ does not result in larger, more inefficient s/w than C (for the correct C++ subset).
The momentum behind the C ecosystem is so overwhelming that Rust simply will not get a foothold anytime soon.
But it only took an afternoon to bolt Rust into the C build because Rust's FFI story is really nice (imo). So I get the best of both worlds: existing C HAL and SDK with the pleasantness and safety of Rust.*
* With the assumption/hope that the HAL isn't buggy, since Rust will rely on that to not explode :)
You could also say this for C on Unix in 1990. Or x86 assembly for PCs in 1985. In 1990, the idea that, 25 years later, we would be deploying network services written in JavaScript was unthinkable.
Change takes time, and C won't die, ever—but history shows that change eventually does happen.
You can still say this on 2017.
No UNIX kernel will ever be written in anything other than C, the way they are married to each other and the way UNIX culture works.
To get rid of C we need to get rid of UNIX, even a POSIX like OS coded in say Ada, needs to expose C like semantics for POSIX compatibility.
Which means we still have a long way ahead in what concerns improving security.
I'd love to learn and start using Rust in our work, but we are client-project-driven, so it will be hard to justify the investment and productivity drop. I think it would make it easier to attract top talent, though things are weird in the embedded world.
Altough most of the units shipped will be above this, won't a decent share of projects(in general ,not just the IOT) be below that threshold ?