Industrial Study Finds Rust Matches C on Firmware Speed and Size

Rust finally has industrial hardware proof

Rust just got the kind of embedded evidence developers have wanted for years: in one industrial microcontroller case, it matched C on both memory footprint and execution speed. That matters because the study was not a toy benchmark or a clean-room demo. It followed two teams building the same IoT functionality over several months, one in C and one in Rust, and then compared how the work evolved on real devices.

The headline result is unusually practical. The measurements on hardware showed no strong reason to prefer C over Rust for this class of firmware on size or speed, and the Rust-based Ariel OS runtime came out smaller than the bare-metal C stack used for comparison. For teams shipping sensors, controllers, and other constrained endpoints, that is not a theoretical win. It is the kind of evidence that can change an architecture meeting.

What the study actually tested

The strength of this paper is its setup. It looked at an industrial use case, not an academic microbenchmark, and it tracked the implementation path over time rather than freezing the code at an artificially polished endpoint. That gives the result more credibility than the usual embedded language debate, because firmware teams care about iteration speed, implementation style, and how the code behaves once it is running on actual hardware.

That real-world framing is important because embedded projects rarely live in ideal conditions. Memory budgets are tight, CPU clocks are limited, and teams have to make tradeoffs that look small on paper but become decisive on a board. In this study, Rust did not lose those tradeoffs by default. Instead, it held its own against C in the exact areas where embedded engineers are most reluctant to compromise.

The authors behind the work include James Munns, Ayushi Sharma, Shashank Sharma, Sai Ritvik Tanksalkar, Santiago Torres-Arias, Aravind Machiry, Elena Frank, Kaspar Schleiser, Romain Fouquet, Koen Zandberg, Christian Amsüss, and Emmanuel Baccelli. That lineup signals another reason the result lands: it is being driven by people already deep in embedded systems, not by outsiders treating firmware as a language exercise.

Why this matters for real embedded teams

This is the point where the Rust-in-embedded conversation shifts from “safer, but maybe slower” to something much more useful. The microcontroller world still lives in the kilobyte-of-RAM and megahertz-clock-speed regime, so footprint is not a side issue. If a language can match C there, while bringing stronger memory safety and cleaner maintainability, the adoption case gets much easier to defend.

That is especially relevant for industrial IoT systems, where code often needs to last for years and failures can mean expensive downtime. A language that can deliver on size and speed while reducing the odds of memory bugs changes the economics of the stack. It stops being a niche preference and starts looking like an engineering option with measurable upside.

The result also lands at a moment when Rust’s embedded reputation is no longer being built only by hobby projects and side experiments. The community has spent years preparing the ground, and this study finally shows what that investment can look like when it is judged against the old guard on hardware.

The platform story behind the result

Ariel OS is a big part of why this study matters. A separate Ariel OS paper said it is the first embedded Rust operating system for microcontrollers to support both single-core and multicore preemptive scheduling together with asynchronous Rust. It also benchmarked the system on ARM Cortex-M, RISC-V, and Espressif Xtensa microcontroller architectures.

That breadth matters because it shows this is not a one-board miracle. The platform work is aimed at making Rust credible across the kinds of microcontrollers embedded teams actually touch, from low-power sensor nodes to more capable connected devices. If Rust is going to be practical in production firmware, it needs an ecosystem that understands scheduling, async execution, and hardware diversity, not just the language syntax.

This is also where the Rust Embedded Working Group comes in. The community created the group in 2018 to help drive adoption, and its vision is to improve the absolute quality and productivity of embedded software while improving the experience for programmers building for embedded systems. The Embedded Rust Book frames the target even more clearly: bare-metal microcontrollers. In other words, the ecosystem has spent years trying to make this exact outcome possible.

What still makes embedded Rust hard

The new study is encouraging, but it does not erase the friction that embedded teams still face. A 2024 ACM CCS study of embedded Rust analyzed 6,408 Rust embedded software projects and surveyed 225 developers, but it also found that most embedded codebases are still written in unsafe C/C++. It described existing Rust software support as inadequate in places, noted that static application security testing tools can miss some Rust embedded features, and said interoperability remains hard because of advanced Rust types.

That is the right caution to keep in view. Rust may now be competitive on memory footprint and execution speed in at least one industrial microcontroller case, but that does not mean every codebase, board, or build system will be equally smooth. Tooling, interop, and platform maturity still decide a lot of outcomes in the real world.

So the practical reading is not “Rust wins everywhere.” It is “Rust no longer has to apologize for hardware cost in the places that matter most.” That is a much stronger position than the community had a few years ago.

Why the broader industry should pay attention

The embedded result lines up with a wider industry move toward memory-safe languages. Google said in September 2024 that Android memory-safety vulnerabilities fell from 76% to 24% over six years as development shifted toward memory-safe languages. Then, in April 2026, Google said it was integrating a memory-safe Rust DNS parser into Pixel modem firmware, which puts Rust directly into security-sensitive, resource-constrained code paths.

That broader shift is the real context for this study. The question is no longer whether Rust is theoretically safer. The question is whether it is becoming operationally acceptable in the hardest parts of systems software, where every byte and every cycle still matter. This industrial microcontroller case says yes, at least for one meaningful class of firmware.

For embedded Rust, that is a milestone with consequences. It gives teams a hardware-backed reason to take Rust seriously not just as a safety upgrade, but as a performance-capable engineering choice. And in a field where skepticism has always been justified by the limits of tiny devices, that is the kind of evidence that changes the conversation.