embedded is a landscape from tiny mcu to imx/h7 style mega beasts; most of the HAL/RTOS/protocols/UI/FS/crypto are in c99; firmware app in c++/rust is possible to take advantage of better abstractions; nobody chooses a language -- however memory safe it may be -- when the whole lifecycle friction is real. besides, rust can't be (meaningfully) faster than c99 in a constrained environment where the resources are typically allocated once and never really released;
I think I probably won't use it. The reason is that the cost of training programmers is high.
Embedded businesses depend on the hardware chain. When the board changes,C and C++ usually receive first-party SDK and BSP support immediately, while Rust support often depends on community-maintained bindings or wrappres.Even if you wanted to use Rust in embedded systems, you'd have to abandon the vast C and C++ ecosystem.
C and C++ have many commercial UI frameworks built with capital from large corporations.
Rust is mature in terms of being community driven, but industry standards are different. Rust's developer experience is actually poor due to the borrow checker. Unlike C, using Rust properly is expensive. Some might say AI can help, but that makes it even more so. And to work with existing C integrated devices, you'd have to use unsafe, which greatly reduces the reason to use Rust in the first place.
So unless the entire vendor SDK changes, it still seems premature.
Rust will still be used for hobby projects, but for commercial use, it still seems painful. However, this might just be because I'm a programmer in Korea. I don't know the situation in the US.
embedded is a landscape from tiny mcu to imx/h7 style mega beasts; most of the HAL/RTOS/protocols/UI/FS/crypto are in c99; firmware app in c++/rust is possible to take advantage of better abstractions; nobody chooses a language -- however memory safe it may be -- when the whole lifecycle friction is real. besides, rust can't be (meaningfully) faster than c99 in a constrained environment where the resources are typically allocated once and never really released;
I think I probably won't use it. The reason is that the cost of training programmers is high.
Embedded businesses depend on the hardware chain. When the board changes,C and C++ usually receive first-party SDK and BSP support immediately, while Rust support often depends on community-maintained bindings or wrappres.Even if you wanted to use Rust in embedded systems, you'd have to abandon the vast C and C++ ecosystem.
C and C++ have many commercial UI frameworks built with capital from large corporations.
Rust is mature in terms of being community driven, but industry standards are different. Rust's developer experience is actually poor due to the borrow checker. Unlike C, using Rust properly is expensive. Some might say AI can help, but that makes it even more so. And to work with existing C integrated devices, you'd have to use unsafe, which greatly reduces the reason to use Rust in the first place.
So unless the entire vendor SDK changes, it still seems premature.
Rust will still be used for hobby projects, but for commercial use, it still seems painful. However, this might just be because I'm a programmer in Korea. I don't know the situation in the US.