Steve has already commented re: stability. Personally I've maintained some Rust libraries for several years, and I don't think I've ever seen a build break beca

Steve has already commented re: stability. Personally I've maintained some Rust libraries for several years, and I don't think I've ever seen a build break because of a toolchain update on a tier 1 platform. (I did see a break on 32-bit ARM that made me use nightly for a few weeks several years ago.) Re: unsafe, there's a similar objection/question that comes up frequently. The Rust standard library is full of unsafe code, as are a lot of common foundational crates. Doesn't that mean that most Rust applications are vulnerable to memory corruption bugs? The short answer is that safety in Rust isn't about having proofs of correctness all the way down. (Some people do that, but they're inscrutable wizards, and I try not to meddle in their affairs.) Instead, it's about having robust and useful ways to encapsulate unsafety. You want to be able to say "if this function is correct, then callers can't use it to corrupt memory no matter how hard they try." Rust gives you ways to achieve that, without paying the cost of a garbage collector or a GIL. In embedded/OS development, the difference is that the big pile of unsafe code underneath is probably written by you instead of by compiler folks. That certainly isn't easy. But the tools for encapsulating it are the same, and the value proposition is the same.