Doesn't C have years and years of repeated security flaws due to lack of memory safety? What's the motivation to continue releasing greenfield projects in C?
Also, while I'm fully on board the "Rust as a default userspace systems language," the machine code I've gotten out of trying #[no_std] Rust to write part of a bare-metal project was heinously bloated. This is without even using any non-libcore dependencies! Something like 3/4s of the machine instructions looked like they were related to building error messages for panics, despite the fact that there shouldn't have been any reachable panics (and the code was small and simple enough that I expected LLVM to be able to reason about this without any MIR-level optimizations).
Maybe this would be better on a project that could use rustc as its linker, but based on this, I wouldn't necessarily recommend that a bare-metal library intended to be linked to C and hand-written assembly be written in Rust versus, say, verified with Frama-C or other C-specific tools.
As you're likely aware, Rust for embedded sucks when there's no HAL, but should be pretty pleasant otherwise. Have you looked into the cortex-a[1] crate?
Some unnecessary instructions could also be a part of an ongoing optimization effort[2][3].
[1]: https://github.com/rust-embedded/cortex-a
[2]: https://old.reddit.com/r/rust/comments/yn6105/optimization_o...
No: not if you avoid memory-unsafe functions. The language does not automatically introduce vulnerabilities.
C has a much smaller footprint and runs on thousands of architectures unsupported by other languages.
heres a shotgun with a hair trigger, now you be careful! shoots face off
C and assembly were the only options. Zig didn't exist back then.
People like C. I like C. I like Rust too but I like C more.
“I like C” won’t sound so good when someone finds an out of bounds exploit on your car update mechanism and manages to load a malicious firmware.