Ask HN: Are you using Rust on embedded devices yet? If not, why?
5 comments
embedded-graphics is a drawing primitive layer, not a UI toolkit, so the gap you're feeling is real. Slint and LVGL bindings are where the polished widget stuff lives on ESP32.
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 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.
One thing I did notice was that creating beautiful, interactive user interfaces on MCUs with displays is a little harder, libs like embedded-graphics don't look that great.
This made me wonder, are people using Rust in their professional embedded work?