These are all real issues with Rust, though it's worth noting that many of the integration challenges mentioned also apply to external code written in C and C++.<p>Some of the survey responses highlight one of the biggest hurdles to rust adoption I've experienced though:<p>Rust has an education problem. People <i>dramatically</i> overestimate the correctness of their [C/C++] code and underestimate the potential severity of failures to meet that expectation. I've found very few projects where a bit of poking can't turn up memory safety issues. Even people who are far more skilled programmers than I am routinely write silly mistakes.<p>Unfortunately the response I often hear to bringing these issues up after the code exists is "it's working code, why should I care about these theoretical issues?"
The overall argument that Rust's use in embedded has a long way to go is fairly accurate. A foundational crate like embedded-hal reached 1.0 only 2 months ago, 8 years after Rust 1.0. On the other hand, this crate reaching 1.0 means the rest of the ecosystem can now mature alongside it.<p>The paper could use a few minor corrections and improvements. For example, they go through thousands of crates in crates.io to give the impression of completeness, but it would have been better to go though a more curated source like <a href="https://github.com/rust-embedded/awesome-embedded-rust">https://github.com/rust-embedded/awesome-embedded-rust</a>. It doesn't matter if the quality of random one off crates that someone hacked over a weekend is poor, it does matter if the crates recommended by the community are poor. But I suppose their analysis would look impressive then.<p>The other nit is that they think that the existence of even one instance of unsafe is a problem. This is a mistake that people unfamiliar with Rust make.
As a rust programmer that programs C++ on embedded, the <i>main</i> thing preventing adoption is the ecosystem.<p>So let's say I happen to work with a MCU that is well supported in Rust, what if I want to connect it to a popular OLED display? Is there a library for that? If so, does it work? If it works, does it have the needed features?
Now maybe I am incredibly lucky and all of that works, what about a popular gyro IC?<p>Granted, there is probably some way to interface the Rust code with C code, but is that gonna work without turning it into a day of research?<p>I will certainly check back on the state of Rust on embedded every now and then, but as of now C++ is my goto.
The paper may be Rust specific, but I found the CVE break down chart on p. 25 interesting. When looking at the percentages of the CVE causes (focused on the 59 bugs classified as those Rust prevents) I got the following:<p>Out of Bounds Reads => 18.6%;<p>Out of Bounds Writes => 62.7%;<p>Null-Ptr Deref => 8.5%;<p>Use-After-Free => 5.1%;<p>Type Confusion, Uninitialized Pointer Access, Memory Leak => EACH 1.5%;<p>I have to wonder about the applicability of these percentages to non-RTOS programming. I find it very interesting that 81% of CVE's are allocated to Out-of-Bound Read/Writes, with writes being the larges percent of those obviously.<p>Has there been any CVE cause analysis performed and publicly available? If so and the percentages bear out similarly to RTOS's across a spectrum of application/system types then there may be some clear cost/benefit analysis needed at the programming language design stage. Rust is a complex language with a complex type and lifetime system to achieve memory safety, and it is not an uncommon refrain that a simpler 'safe' language would be appreciated by many developers. If 80% of CVE's come from Read/Write errors on array access, then a language that enforces strict memory access semantics, but forgoes the rest of Rust's complexity regarding lifetimes and type system complexity would achieve a very large portion of exploit prevention at a minimal cost.<p>Additionally, if you prevent Null types in the type system the language would then prevent 90% of CVE causes, again with a minimal amount of complexity.<p>I'm not certain that the above is correct, if the percentages play out in the large, or that devs would actively switch to a considerably safer, while being simpler language. But it certainly is thought provoking.
Personally in the past ~2 years I have been trying to shift my code base to rust when it comes to robotics and drones software, the biggest issue is the integration part, most “addons” that you can integrate with the robots like Lidar and other sensors come with the usual SDKs in C/C++ or even python. Additionally, most of X-rust converters don’t really work so you end up rewriting it from scratch.
my takeaways:<p>1. <a href="https://arewertosyet.com/" rel="nofollow">https://arewertosyet.com/</a> to track rust RTOSes and their status<p>2. there are tools to convert c to rust (I dont know if I'd trust this..)<p>3. "Out of 43 different MCU families, peripheral crates are currently available for only 16 (37%). Most of these crates are generated using svd2rust utility"<p>4. developers considered but rejected rust because: "Lack of Support for MCUs (36%) ; Difficulty Integrating with Existing codebase (32%) ; Organization constraints and certification requirements (30%)"<p>5. "The second major (26%) issue is debugging, which is expected because, as explained in Section 2, embedded systems follow an asynchronous and event-driven design. This results in frequent cross-language domain interactions and makes debugging hard."<p>I would adopt rust if it were easy to get up and running just while(1) loop applications.
"Embedded" is a diverse concept. No need for Rust on ATtiny with all variables static and Harvard architecture. In fact, even C often is overkill, and Assembler is a better choice for a simple LED flasher or really tight high performance loop.
I think when bringing up embedded rust it is necessary to specify an application.<p>For low level, hard realtime control and interrupt handling rust gets in the way. Many embedded applications stop here. For things like parsing, protocol stacks and business logic rust has a clear advantage. Interoperability with C is therefore essential. The current situation is good for ARM and RISC (ESP32) but impossible for weirder stuff like C28x. (See my demo here: <a href="https://github.com/driftregion/bazel-c-rust-x86_linux-armv7_baremetal">https://github.com/driftregion/bazel-c-rust-x86_linux-armv7_...</a> )
If you're using Stm32s or Nordiks (among a few others) then I cannot recommend enough the Embassy framework.<p>I used it for a custom board I made and it not only consumed less power overall due to the automatic chip sleep state handling but has been drastically easier to work with than the provided C firmware.<p>Developer is also super responsive on Matrix and a nice guy.<p><a href="https://GitHub.com/embassy-rs">https://GitHub.com/embassy-rs</a>
I spent a weekend with Rust, a Raspi4, and our buddy GPT about six months ago. In that weekend I was able to get the Raspi controlling a OLED display via SPI with an SSD1306 controller. I thought it was a fairly clean port from C++, and GPT was well educated on how to use the RASPI SPI and I2C busses from Rust.<p>I don't think I would be able to approach it on an ESP32 or AVR xMega or some other real microcontroller.
Honestly, the biggest thing that concerns me with using Rust for embedded is the size of the crates. We were looking to do some packages for a product, and the Rust packages were huge compared to the C++ ones. Granted, this was mostly because the C++ ones could use .so's, while Rust had to compile those into the crate, but this is a huge issue when doing OTA updates.
I've been trying out embassy-rs and what is really exciting that you might get RTOS abilities, without actually using an RTOS. Just native Rust, with some smart abstractions. Still prefer C, but the Rust embedded community seems to be cooking up something very interesting.
I wonder how would the performance of Rust be without the runtime checks and the std_library.<p>And why is the std_library less performant than, let's say, C's counterpart?