Live data from Hacker News

Should you Rust in embedded yet?

kazlauskas.me

1–10 of 119 posts

Re: Should you Rust in embedded yet?

#2
Having 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 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?

#3
post #2

Having 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?

#4
If anyone out there is an embedded developer curious about how Rust works in this space in practice, or a non-embedded developer curious about how to develop on embedded, there's a really fantastic (and free) ebook, "Discover the world of microcontrollers through Rust" (https://www.reddit.com/r/rust/comments/80doqg/discovery_disc... ), by Jorge Aparicio (the premier guru of embedded Rust development), and recently updated for 2018.

Re: Should you Rust in embedded yet?

#5
post #3
post #2

Having 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?

Ideally I'd like to see Rust used to ship in production systems. I do a lot of IoT, and I don't see any of my customers green-lighting Rust until the silicon guys say "yes, we'll support Rust" and provide official HALs and support.

Re: Should you Rust in embedded yet?

#6
post #2

Having 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…

I know this won't assuage your concerns about officialness, though it's still worth mentioning that Rust does have community-maintained HALs (https://github.com/japaric/embedded-hal ) and tools to generate APIs from official vendor-provided SVDs (https://docs.rs/svd2rust/0.12.0/svd2rust/ ).

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?

#7
One definition of "embedded" is: does the user treat it like an appliance or like a computer? If it's the former, it's 'embedded' even if it uses a reasonably powerful processor or does not have hard real time requirements.

I 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?

#8
I'm completely in this boat at the moment. We are doing a hardware refresh of our embedded platform and I'm looking at the feasability of using Rust.

I'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?

#9
Embedded developer here, ARM Cortex-M4 microcontrollers. I've been keeping an eye on Rust for the embedded space and although there has been a lot of movement in that area--particularly in the last couple of months--I'm not sure the value proposition fits the microcontroller market, where of course C is king.

While 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?

#10
post #2

Having 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…

> Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust.

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.

Post reply on HN