Should you Rust in embedded yet?
kazlauskas.me
Should you Rust in embedded yet?
1–10 of 119 posts
Re: Should you Rust in embedded yet?
#2Most embedded systems are fairly closed ecosystems built on vendor-specific stacks, and most professional embedded engineers wouldn't want to use Rust until the vendors support it.
This isn't to say the hobby world (ala Arduino/Raspberry Pi) wouldn't benefit from Rust, but I think the long-term viability depends on the ARMs, STs, TIs and Renesas' of the world starting to embrace Rust. To date I haven't seen this happen (although I'd love to be proven wrong!)
Edit: just noticed the recommendation to use a Blue Pill for Rust dev. They're cheap on eBay (just picked up 2 a few days ago)
https://www.ebay.com/itm/STM32F103C8T6-ARM-STM32-Minimum-Sys...
Looks like here is a supported Rust BSP, too:
https://github.com/japaric/stm32f103xx-hal
Anybody have any experience with this?
Re: Should you Rust in embedded yet?
#3Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust. The article doesn't directly call this out, but I think it's important for Rust to truly succeed in this space. Most embedded systems are fairly closed ecosystems built on vendor-specific stacks, and most professional embedded engineers wouldn't want to use Rust until the vendors support it. This isn't to s…
Re: Should you Rust in embedded yet?
#4Re: Should you Rust in embedded yet?
#5Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust. The article doesn't directly call this out, but I think it's important for Rust to truly succeed in this space. Most embedded systems are fairly closed ecosystems built on vendor-specific stacks, and most professional embedded engineers wouldn't want to use Rust until the vendors support it. This isn't to s…
Specifically what level of support are you expecting from ARM, ST or TI?
Re: Should you Rust in embedded yet?
#6Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust. The article doesn't directly call this out, but I think it's important for Rust to truly succeed in this space. Most embedded systems are fairly closed ecosystems built on vendor-specific stacks, and most professional embedded engineers wouldn't want to use Rust until the vendors support it. This isn't to s…
There's also a few boards out there that do support Rust natively: Hail (https://www.tockos.org/blog/2017/introducing-hail/ ) and Tessel (https://www.tessel.io/ ).
Re: Should you Rust in embedded yet?
#7I use Erlang for that kind of thing and it works well. Rust is, I think, more performant, so if that works for you and what you need, go for it.
Re: Should you Rust in embedded yet?
#8I'm at the point where I think it is close to being viable, but seems very young. Most likely we will go with a platform that can support rust, and write the low level modules with the intent of using rust, but not use Rust just yet, but do a side project to asseses the viability of doing as much of the software in Rust as we can. ( and get the devs learning Rust ). I am what I like to call a multi stack developer, so I'm super comfortable with a lot of languages and platforms, but the embedded devs I work with are microcontroller focused C devs and it will take some time to be convinced, conceptually they like the idea, but as soon as they try and write something serious they are going to feel frustrated and likely make a mess.
But Rust has a LOT to offer the embedded world.
Re: Should you Rust in embedded yet?
#9While Rust has much to offer as a programming paradigm in general, the main value is in the borrow-checker (the linked transcript cites 'memory bugs' as the most common class of bugs). Embedded software practitioners long ago abandoned dynamic memory allocation and with it the 'use-after-free' and 'out-of-bounds access' bugs, instead re-defining the problem as one of latency (e.g. you'll need to process that static buffer before it gets re-used by your UART interrupt). Take away the borrow-checker, and Rust looks less compelling.
In time, Rust will find its niche in the embedded space, most likely occupying the high-level RPi/BBB/iMX SoC layer and perhaps working its way down to microcontrollers. As wiremine points out, it will require vendor support--moving away from your vendor's toolchain is a world of hurt that seasoned embedded developers just won't even consider. Pragmatism reigns: time-to-market and a cheap BoM are the main metrics, programming language a distant 10th.
Re: Should you Rust in embedded yet?
#10Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust. The article doesn't directly call this out, but I think it's important for Rust to truly succeed in this space. Most embedded systems are fairly closed ecosystems built on vendor-specific stacks, and most professional embedded engineers wouldn't want to use Rust until the vendors support it. This isn't to s…
So one thing I noticed from the micropython world is that chip makers are not going to support micropython. But there are third party companies that are supporting python on specific microcontrollers.
One problem the chip makers have right now is language frag. Rust is competing against go, python, kotlin/native, swift, javascript, and others. Rolling a tool chain is not free, because it needs to be updated over time for optimizations and code fixes.