"Based on our findings we can conclude that Rust is a very well-suited programming language for writing network drivers. It is not only a fast and safe systems programming language but was also voted most beloved programming language in 2016, 2017 and 2018 [15, 16, 17]. Writing more drivers in Rust would certainly lead to safer and more reliable computer systems."
Working link to their code: https://github.com/ixy-languages/ixy.rs
> An OS kernel — despite its historic appeal and superficial fit for Rust — may represent more challenge than its worth
However it suggests more hybrid approaches:
* asm/C kernel with Rust kernel components like drivers and filesystems, Rust can be used for new developments and enable an incremental introduction, mentions a prototype example in freebsd
* Rust for non-kernel OS components: an OS is not just a kernel and utilities, daemons, management facilities, debuggers, … bundled as part of the system tend to be more prone to run-time failures than the kernel itself (and more commonly face hostile interactions), making them excellent candidates for Rust
* Rust-based firmwares: firmware is "a sewer of unobservable software with a long history of infamous quality problems", some areas of firmware (and kernel) development are weak in rust (e.g. dealing with allocation failure) but that aside it looks amenable to Rust
Also, it really comes down to whether or not it's a long-term win. Apple certainly has the capital to make it happen if they decided it was worth it.
For instance these past few days I've been writing a small bootloader for some embedded ARM chip. I pondered going with Rust but ended up using C for two main reasons:
- I know that if it's doable in Rust it's doable in C but the opposite is not always true (or straightforward). In particular bare-metal/very low level Rust is still somewhat experimental, you can't use stable Rust if you want to be able to use inline ASM or other advanced features. I have very tight constraints regarding code size and memory use and I was concerned that I might not control that as effectively with Rust code than with C.
- There's already a bunch of C code written for this chip that I can reuse without any friction (no binding generation, no ffi etc...). The vendor even provides a huge header file with the full memory map and some code to init the PLLs.
If you're coding in a vacuum then how "beloved" a language is is mostly irrelevant but if you want to benefit from the ecosystem then having a language that people want to use and support is extremely important. The tooling will mature and stabilize as more and more people use Rust to write bare-metal code and device drivers, which will eventually make my first point above irrelevant. Then if the language becomes popular enough it will be easier to find Rust code or pre-made crates to do what you want which will hopefully eventually solve my 2nd issue.
Since I can't get u-boot to create a small enough image with all the features that I want (and also because I want to add vendor-specific customizations on top) I decided to try and rewrite a small, single purpose loader from scratch. I considered Rust but then that meant that I'd have to port or rewrite all of u-boot's code I want to reuse (especially the vendor code contributed by Altera mentioned in the previous post). So C it is.
It's the second order effects that matter.
Still, I do think you're right that a significant number of people hate C++, so I think your point is still valid.
Heck, in some industries, like aviation, even something subjective like boredom can kill.