Partly because it's an ecosystem that I'd like to see grow. More people using it means that the other Rust-based projects I use will be better too.
Partly because it is the "carbon fiber" of programming languages. Just its use is something you can use to market to other engineers.
Partly because it's very ergonomic and I enjoy working with it. I'd much rather dive into esoteric Rust code than esoteric C code.
Partly because code written in of Rust will have less errors than code written inside of C. It isn't just memory safety - it's all of the type theory/best practices we figured out in the last 50 years.
I understand why it was written in C. It's an easier language to work with and they probably needed something out quickly. But coding in Rust is a sign (not proof, but a sign) that a program is of quality make.
For this type of unikernel project C makes sense. I’m a fan of both C and Rust. I like that Rust prevents typical code safety problems, but I like that C hardly changes over time whereas younger languages like Rust are constantly changing. It’s plenty possible to write correct, clean, memory-safe, and understandable code in C, especially if verified by extensive fuzz testing and code scanning.
It’s really small. I know c doesn’t translate to rust, but it would be a good template for someone doing that. You need the state in an os, and using threads as memory containers is a bad idea here. But you could certainly do the array thing or arc everything steal the interrupt notion from the embedded rust community, write a different async runtime and that would get you most of the way
