Re: You spend a lot of time talking about C++
The C language is efficient (and close to the assembly language it's compiled into) because it _IS_ by design.
I'll defer to Bryan Cantrill on that one:
Historically, C has been the best fit for these applications just because [it's] so lean: by providing essentially nothing other than the portable assembler that is the language itself, it avoids the implicit assumptions (and girth) of a complicated runtime. But the nothing that C provides reflects history more than minimalism; it is not an elegant nothing, but rather an ill-considered nothing that leaves those who build embedded systems building effectively everything themselves — and in a language that does little to help them write correct software.
Now it seems that a SUBSET of Rust is being considered. That may be acceptable, just like a subset of C++ is used on microcontrollers that use the Arduino IDE.
...and this is something the Rust developers officially encourage, with:
1. A standard library that's split into layers so you can keep the core primitives and disable the stuff that's only applicable to userland coding.
2. A linter that's part of the official distribution with plenty of lints to enforce project-specific requirements such as "no use of floating point values".
3. The ability to forbid(...) warnings and lints, turning them into compiler/linter errors which can't be selectively re-enabled.
So I would want similar from Rust: interoperability and fast/compact code should be number 1. Having a bunch of "but if" and "just in case" [paranoid] data checks and double checks in the code [thus stealing CPU cycles for pointless error checks] should be EXCLUDED (and such checks performed MANUALLY by coders, instead, like in C]. Automatic "features" that create inefficiency, in other words, should NEVER be used in the kernel.
The kernel guarantees certain things are valid. Properly written drivers would do the same thing. if it is necessary to add code that double-checks parameters to guarantee valid data/pointers/etc. then you might as well be WINDOWS. Linux should be SO good that such things are NOT necessary.
Rust tries to encourage that through good API design which allows it to be proven at compile time that the invariants will be upheld, thus avoiding the need to choose between safety and performance.
My favourite example of that is "the typestate pattern" which lets you teach the Rust compiler to prove correct traversal of any state machine, forbidding things like "Tried to set HTTP request header after the body had already begun streaming" at compile time.
A more mundane example would be the iterator APIs. No need for bounds checking if the iterator looks up the length once at the beginning and the APIs prevent you from wandering out of each entry it hands you.
From what I've seen, Rust programs tend to run faster than their C and C++ counterparts because the developers feel comfortable introducing and maintaining more aggressive optimizations.