Re: You spend a lot of time talking about C++
and there are MANY reasons why C++ is not being used within the kernel.
all of that housekeeping for unwinding things in the event of try/catch is number one.
And the fact that try/catch exists is unfortunately an indicator that if C++ *WERE* used n the kernel, a bunch of clueless newbies would try making use of it... to the detriment of EVERYTHING. Point is, if a lingo has "a feature" some people will eventually use it, even if it is BAD to do so.
it falls under "just because you can, does not mean you should". And I include Rust in that analysis as well.
The C language is efficient (and close to the assembly language it's compiled into) because it _IS_ by design. it's more or less why the language was invented, back when UNIX was ALSO being invented and it needed to be programmed in a language that was close to assembly, but portable enough to compile on multiple platforms.
Let's NOT just throw caution to the wind and adopt an incompletely tested programming lingo just because "Junior" likes it.
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. Some of C++'s more aggregious "trying to be all and do all" quirks have been carefully omitted, with respect to startup code and constructors and other things that just bloat up a limited program memory space. It's all documented over on the avr-gcc web pages at any rate.
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.
(so that gets back to how Rust is expected to be used, but I suspect perormance prioblems WILL be the most immediate concern and Linux runs on embedded and low clock speed devices for the very reason that it is STILL small and efficient by comparison to other things. Like WINDOWS)