In general, C is a better option if you find you are escaping to macro defined Assembly or other memory ops (glib back-ported data structures for C highly recommended). Rust likes to keep unsafe operations organized, but is a persistent pain if a problem scope requires many "unsafe" operations.
I'd wager Rust will end up like Boost... really cool.. but too chaotic to trust past 10 months. =)
Rust is replacing C++ in several well documented places, however C++ itself was a replacement for C in many places. So by definition the use-case for Rust overlaps the use-case for C.
Arguments like this sound like old arguments that were re-told to me by my father where people argued that C couldn't replace the use case for Algol at the University of Michigan MTS system. (Assuming I'm remembering the second-hand argument right. I'm a second generation software engineer.)
Also, there's nothing of note in the last 10 months about Rust that's different from the 10 months before that.
Actually, Cpp originally was a C template pre-compiler if I recall... just like Rust was. Note, people argue for years about various language merits.
"there's nothing of note in the last 10 months"
Indeed, still a pain to build, port, and package on some systems due to the poor project design required dependencies. There are papers pointing out the common fallacy of increased memory safety with the current Rust builds as well.
Of course, Rust may work fine for whatever you are building. =)
So when he started at Bell Labs and all it had was C, he quickly got busy getting his high level tooling back.
Being a C preprocessor was the quickest way to achieve that goal.
The problem with those comments is that they are intellectually lazy, and use age as a proxy for "better". Language X can be designed with specific features in mind that offer interesting features that Language Y fails to offer, but that is not ensured by the release date, nor might that be an acceptable tradeoff when considering other factors.
https://en.wikipedia.org/wiki/Second-system_effect
i.e. the attempt to "improve" ultimately adds additional complexity, and defeats its stated purpose due to conflicting use-cases.