Embedded Rust in Production?

I remember looking into Rust for a personal project, on embedded, in 2016. After poking through all of it I decided against doing that because it was clear I'd be spending a lot of time getting Rust working at all instead of doing anything for the project itself. So C it was.

The thing I have to say in the context of the article is this: There is no way to know whether a complete rewrite in C would have yielded similar results to Rust. The phrase "C prototype" made me squirm, even more so when reading that in the context of critical infrastructure. It is known by now (or should be) that such prototypes live on like zombies, so unless it is really some throwaway (from the point of architecture!), these things tend to live on for longer than most feel comfortable with. And, being so critical in function, maintainability is one of the primary concerns.

Yes, Rust will, eventually, at some point, maybe? the go-to language we use in the embedded field, but we are talking not just about a language replacement, we are talking ecosystem replacement. That is not going to happen overnight.

That said, as some mentioned Java, Perl, and such things: I revived a personal Perl 5 project not too long ago that was more than 20 years old by that point. Needed a small change because the latest installment of Perl 5 is a bit more restrictive with some borderline syntax things (good), but other than that it just worked. In the larger context of the project there is also some C code for binary file processing, also >20 years old. Needed a renaming of a POSIX function (arguments and functionality all the same, though), and then it worked, even compiled as native 64 bit code. Granted, there are not that many dependencies beside POSIX, and the code was even back then written to a level of quality that allowed it to run on all sorts of (POSIX) platforms already.

Which is why "C prototype" sounds to me like "we cobbled something together", and all sorts of bugs are no surprise then. You can cut only so many corners before it becomes an issue, especially in software that is used all the time and in a critical place of a system. This needs to be done right, else you will waste a lot of time (and money!) afterwards.

Imho Rust will be not much further in embedded world in 2026 than it was in 2016. I managed to get in the role where I have hiring decisions to make. From this perspective I need somebody to be able to work with existing projects in C from the 2006 instead of knowing cool new language. There is no single advantage for a company selling products to change the language used. Transition will only cost money.

Regarding C prototype. I wrote it. 6000 lines of code, works nicely, 4200 lines of code were Xilinx driver calls to move data between the hardware blocks. So changing the language will not really bring any benefit. Maybe even opposite - one must study the register calls and read data sheets to create equivalent functions in other language. The code wasn’t beautiful, was created as “prototype” and was at the end the version shipped to a client.

I made this with rust in 2020 http://yager.io/vumeter/vu.html

The embedded rust ecosystem has invanced a pretty insane degree since then. I have an ongoing embedded project and I have had to use C FFI calls a total of zero times in a ~100kloc codebase. There are native rust HAL libraries autogenerated from manufacturer published device specs that are insanely good, and take advantage of rust type system features to offer vastly superior APIs compared to mfgr provided C libs

Thanks for sharing. Some link to software section ends in „File not found”.