Ask HN: Has any Rust developer moved to embedded device programming?

Honestly just a global

   char foobar[256] = {0};

It's quite common in hard real-time systems, especially in aeronautics, to only allow malloc on startup if it's allowed at all. There are many problems with malloc() and especially free() - they typically don't have any maximum latency guarantees, and even worse, what happens when you can't get memory (e.g., due to leakage or poor packing)?

In many systems this isn't a problem. The number of engines, flaps, etc., don't change at run-time :-). If they change, you're on the ground in maintenance mode and can reboot.

I'm fortunate enough to have just landed on a new team working with embedded Rust. Here are some of my takes, in no particular order.

The language and ecosystem have come a long way in a very short time. It's easy to use safe `no_std` Rust on the stable toolchain for 98% of your code, and there are crates available for all kinds of things like memory management, register access, or even async runtimes.

Compared with C, Rust is absolutely a game changer in terms of reliability/safety/productivity. Every line of C code is a potential liability, because humans make mistakes. Having a compiler that smacks me down is invaluable; it results in a safer and more reliable program, and it helps me get it right the first time. Like many others, my experience with Rust is nearly always "if it compiles, it works". This is _especially_ valuable for embedded programming, because debugging is often way harder when working with hardware.

One major drawback is lack of support/engagement from hardware vendors. They pretty much assume you are using C, and all of their IDEs/SDKs/codegen tools/whatever are written with that assumption. This probably isn't going to change any time soon (ever?). What this means is that if you want to use Rust, you'll be on the hook for figuring out a lot of low-level things like linker scripts, boot sequence, or memory/clock initialization. Often this means reading or reverse-engineering the vendor's SDK to figure out how these work. If you're working at a big company on a serious product, you might have done this anyways. But for a hobbyist, this can be a huge barrier.

I recently moved to an embedded software role. I sought out this move because I love writing code for very small computers, fiddling with registers, Blinky lights, etc. I didn't realize how important an accredited RTOS was for many commercial projects. It's not really about middle-aged devs being stuck on grungy-old tech. It's about being able to support a device for the next 10, 20, or 30 years with a consistent tool chain. This is especially true for devices that have some sort of industry accreditation, like medical devices. It's very expensive to get that accreditation and if you change the embedded language, that will probably start the process all over again.

That doesn't mean there aren't companies looking at Rust, because C code is hard to get right. We use a mix of emulators, FPGA simulators, unit testing, static analysis, manual code reviews, and various coding standards to try to avoid introducing a bug. It would be nice to work in a language that took certain classes of memory errors off the table. I'm sure Rust has some monsters lurking in the shadows, but at the level I've tried to adopt it, I haven't found them.

With that out of the way, I like Rust. I think there's good quality basic tooling like IDE support and debugging. but It's a little bit of a crap shoot as to what board support you can get. A lot of times I've been able to get by with "close enough" HAL crates. Chances are you will find a board but may have to write a driver for a particular device. (By driver I mean something that understands how that device works and knows what bits to write at which address to set registers, or I2C commands, or whatever). It's not as bad as it sounds, but you will learn to read spec sheets. Many CPU's are a mix of features supported by the IP the chip manufacturer decides to put into their product. Like they might not support some optional components in that specific chip.

Be careful about ESP32. I believe some are based on the Extensa cores and I think some are based on RISC-V. Those are different architectures. I agree with the people below that recommended STM32 which is a more predictable ecosystem since they're all ARM. M0, M3, M4, etc. are all well understood, highly supported cores. ST's licensing (I believe) requires you get a license for the IP before you can distribute a commercial product based on their architecture. I haven't looked at Espressif's restrictions.