Rust is _a_ safe language, but if you're interacting with a lot of low-level hardware, you end up with a lot of unsafe {} code and manual analysis that takes away some of the advantages.
I see Rust as a C++ replacement more than a C replacement. I'm not sure if object oriented languages (well, "struct with functions" in Rust's case) with vtables and dynamic allocation and the like are a good match for that kind of code. Rust, as a language, simply can't deal with running out of memory; all allocations are assumed to succeed, which is a dangerous assumption, especially in low-level code like this.
Unfortunately, we don't really have a common C replacement with Rust-like safety guarantees. I'm hoping Zig will be able to provide some safety to the C ecosystem, but it's still a ways away from 1.0.
> UEFI/BIOS is not a bootloader
You're right, I meant "bootstrapping system". I'm sure there's better terminology here but the word escapes me at the moment.
Rust, as a language, doesn’t know anything about heap allocation. The “running out of memory” stuff you’re talking about is a feature of some APIs of the standard library, which you often completely forego in an embedded context. Or you can use the (still unstable, to be fair) APIs that return results instead. This is what the Linux kernel is doing, for example. It was a hard line for Linus, but didn’t prove to be an obstacle in the end.
One could, of course, write their own allocator and heap tracking system as part of the UEFI firmware, or reimplement the entire thing without any of the standard library and simply relying on the core library, but if you want to deal with fallibility, you'll have to reimplement every part of the language toolkit and use Option<> or Result<> for every API call, which would only complicate the rewrite more.
I see Rust as a C++ replacement more than a C replacement. I'm not sure if object oriented languages (well, "struct with functions" in Rust's case) with vtables and dynamic allocation and the like are a good match for that kind of code. Rust, as a language, simply can't deal with running out of memory; all allocations are assumed to succeed, which is a dangerous assumption, especially in low-level code like this.
Unfortunately, we don't really have a common C replacement with Rust-like safety guarantees. I'm hoping Zig will be able to provide some safety to the C ecosystem, but it's still a ways away from 1.0.
> UEFI/BIOS is not a bootloader
You're right, I meant "bootstrapping system". I'm sure there's better terminology here but the word escapes me at the moment.