&quot;General issue: C and C++ have an advantage in the sense that we understand their many problems well due to their long history, and they have formal specs that are far more carefully written than most others, where documentation is spotty and formal specs are often lacking. &quot;<p>See, even that is misleading. The C specs have a ridiculous amount of undefined behavior and dark corners that can mess up developers. C++ probably does too more than I know. Their specs are actually so hard to formalize that people got Master&#x27;s degrees, etc for pulling off part of that after <i>decades</i> of people trying. Whereas, many LISP&#x27;s, ML&#x27;s, and Wirth languages (eg Oberon&#x2F;Modula lines) were described quite succinctly and including code. C &amp; C++ specs are so horrible you can&#x27;t even be sure what your code will do even if you write it to spec. !?<p>&quot;Example: I have not studied Rust closely, but it seems to me that there are sections that essentially must be placed under &quot;unsafe&quot; for performance or low level access.&quot;<p>Others are addressing the point about Rust, which I&#x27;m ignorant about. What I can say is the generic rule on this issue. Most safe-by-default type languages wrap unsafe behavior behind function calls which still have type&#x2F;interface checks. If that code behaves correctly, you get to leverage type system of safer language to make sure it works with the rest correctly. If it behaves incorrectly, one of two things happen: local damage where an incorrect result is obtained; application crash or hack. You wouldn&#x27;t be using the unsafe code unless you thought it was necessary. So, doing safe + a little unsafe adds no risk vs going all unsafe in C, etc. Yet, it counters many risks. So, it&#x27;s a good tradeoff even if unsafe code can have unpredictable effects on the rest.<p>Note that one can attempt to further mitigate without sandboxing by writing that unsafe code in a way amendable to static analysis or through testing of what it does. One can use something like Frama-C or SPARK Ada to model that one part to make it as bulletproof as possible. Only then include that algorithm into the otherwise safe program. And again wrapped with interface safety to counter even more risk.<p>C and C++ will always have an advantage over sheer momentum. However, there&#x27;s always alternatives available that lack the problems of the above. They don&#x27;t have to have the GC, portability, and size issues as Ada and Wirth&#x27;s languages always showed. I mean, Wirth&#x27;s Pascal&#x2F;P was safer than C, efficient (although not max), and more portable given backend was simple, stack-machine anyone could implement. It was ported to 70+ architectures that differed <i>a lot</i>. The ports of Oberon compiler and OS to each new hardware took 1-2 undergrads under 2 years each time due to good design, modularity, and simplicity. What kind of effort have the UNIX&#x27;s and C compilers took to put on each new architecture? ;)<p>Anyway, I agree if you want max contributions by existing programmers that C is likely best choice for OS development. Or at least the kernel of something like JX Operating System or VerveOS where rest is done safely. If you want <i>best results</i>, then avoiding C and using safer alternatives is best. You&#x27;ll get so much more done w&#x2F; higher robustness in the time you save debugging. :)