September 02, 2025
Story
The code battle between Rust and C feels like it’s been heating up all year, and some folks are starting to pick a winner, at least in particular cases. Rust and C can both offer good performance and control for embedded hardware and systems, but the differences seem to end there.
C has all the advantages of maturity and experience (never underestimate an old gladiator). Its long history and broad ecosystem makes C the reigning monarch of embedded code with frameworks and libraries for almost any extant use case readily available.
Don’t count Rust out so soon, though. The newer codebase carries the advantage in memory safety, especially in new systems without a ton of legacy code. Rust is also simpler and easier to use, so many users report that it’s speeding development times on projects, too.
We wanted to get to the bottom of this, so we opened the floor to the Embedded community to see what they would say when asked:
Will Rust replace C?
Brendan Bogan-Ware, Founder and Lead Engineer for Bloxide
Short answer: Yes. But the real driver isn’t language features; it’s how embedded teams will work in the AI era.
Can Rust completely replace C?
Not yet: there are some legacy targets that may never support Rust. But most new designs can choose hardware and toolchains that fit Rust. From a technical perspective Rust can do everything C can do since it compiles to the same machine instructions. The limits today are in toolchain maturity, vendor inertia, and workforce training. Luckily, the Rust ecosystem is becoming more mature every day, and workforce training can be accelerated with AI tools.
Will Rust improve end products?
Yes: by changing failure modes. Ownership and lifetimes remove entire classes of memory errors, cutting late-stage defects, warranty costs, and security risks. However, there will still be some niche projects with ultra-tight SRAM requirements or specific SDKs.
Regulation and market trends
The European Cyber Resilience Act (CRA) will hold manufacturers liable for connected-product security flaws. Paired with the boom in manufacturing automation, IoT, medical devices, and smart homes, we’re entering a golden era that demands far more embedded software. Memory-safe languages like Rust reduce the opportunities for security problems, which helps the bottom line over the life of a product.
The AI effect
AI is pushing us into the future faster than any single technology shift in the past. If we assume code output quality continues to improve, the only objection left for today’s software developers is that AI-written code is “less fun” to write. For business, that’s like craftsmen resisting automation: irrelevant to market survival. The reality is that AI is already writing embedded software and will write the vast majority of embedded code moving forward. In C, that’s a minefield without heavy oversight. In Rust, the language itself enforces a baseline of safety and reliability. The winning teams and companies will be those that combine AI codegen speed with disciplined, automated verification pipelines to deliver secure, production-ready firmware at scale.
Verdict
Rust will dominate new embedded projects in an AI-driven, increasingly regulated future. The real question isn’t if Rust replaces C, it’s whether our teams and processes can keep up with how fast AI is changing what “embedded development” means.
Tim Reed
CEO of Lynx
C has been the foundation of systems programming for decades. Its simplicity, predictability, and ability to interact directly and efficiently with hardware with minimal abstraction or overhead make it ideal for kernels, embedded systems, and real-time applications. It is deeply entrenched, supported by mature toolchains and well-established certification workflows. Replacing C completely will be hindered by return-on-investment (ROI) considerations. For some systems, the benefits Rust offers in terms of safety and reliability may justify the cost. And if generative AI can dramatically reduce the cost of translating C code to Rust, while simultaneously resolving all of the data design and memory bugs, adoption could accelerate.
Rust provides memory safety and enforces strict static typing without using run-time garbage collection. These qualities make it particularly well-suited for developing embedded safety-critical applications. Rust also eliminates common bugs found in C such as buffer overflows and use-after-free memory access. By addressing these issues at compile time, Rust can reduce the cost and effort of verification and validation, which is a major hurdle in certifying real-time operating systems.
The language is seeing growing adoption across these sectors, particularly for new projects that demand stronger safety guarantees, better long-term maintainability, and higher developer productivity. That said, Rust isn’t a full-on replacement.
For example, the ongoing effort to integrate Rust into the Linux kernel reflects both the promise and complexity of shifting away from C in foundational software. Around 70 percent of high-severity security bugs in Linux are caused by memory safety issues, many of which Rust can eliminate at compile time. But challenges such as interoperability with C, kernel API wrapping, and tooling gaps remain challenges, resulting in the community focusing on layering Rust safely to avoid regressions while modernizing selectively. This initiative serves as a powerful bellwether for broader industry transformation, showing how even the most mature and performance-critical systems are beginning to embrace the change.
Rust isn’t here to erase C, but to evolve what’s possible in systems programming. Replacing legacy assured C code can be costly, especially in safety- or certification-critical environments.
But for greenfield projects, Rust is increasingly the smarter choice. It offers stronger guarantees around safety, concurrency, and maintainability, even in low-level embedded environments where C once reigned alone. The coexistence of C and Rust will persist in the near term, particularly in mature, proven-in-use codebases. But the long-term trajectory is clear: where ROI permits, Rust is poised to become the dominant choice.
Rolland Dudemaine, Director, Field Engineering at TrustInSoft
Rust has taken lessons from many languages, including C/C++. Adoption is no longer to be demonstrated. Interestingly, this adoption comes from two culturally separate ends of the world, with web browsers and desktop environments on one side, and embedded on the other.
Several projects are moving forward with the adoption of this new language, but different strategies are applied:
Innovation projects start fresh with a pure Rust implementation, without legacy code.
Generational projects have new code written in Rust, but legacy, stable C/C++ code is left untouched, under the wise rule of “if it’s not broken, don’t fix it”.
Some critical projects, in all verticals, still consider the move to a full renovation or a multi-language setup to be a significant risk and keep their current practices.
Ultimately, what will probably happen is a balance: in the history of computing, there has never been a situation where a single language has taken over the world. But migration is happening, indeed!
Stephen Hedrick, Technical Product Manager for Rust at AdaCore
The short answer is no. Rust will not completely replace C, nor should we expect it to. Just as assembly language persists decades after higher-level alternatives emerged, C will remain relevant for novel hardware platforms and severely constrained environments where its simplicity and universal toolchain support outweigh Rust’s safety advantages.
However, this misses the more important question: should Rust replace C everywhere it’s practicable? Here, the answer is yes.
The fundamental issue isn’t about language preference but rather risk management in an increasingly connected world. Memory safety vulnerabilities represent a significant portion of security issues in major software systems, a point that becomes particularly alarming when applied to critical infrastructure. While C’s manual memory management offers theoretical control, the practical reality is that even experienced developers struggle to consistently avoid the pitfalls that Rust’s ownership model eliminates by design.
Explicit government endorsement is accelerating the transition from C to Rust. The US Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), and Office of the National Cyber Director (ONCD) have all issued guidance favoring memory-safe languages like Ada, Rust, or SPARK for new development. This isn’t ideological; instead, it’s a response to decades of preventable vulnerabilities that have compromised critical systems. Similar regulatory momentum is building globally, suggesting that memory safety will increasingly become a compliance requirement rather than a best practice.
The ecosystem supporting this transition is maturing rapidly. Rust’s vibrant community has produced an extensive crate ecosystem that rivals established C libraries in many domains.
Vendors are providing and advancing enterprise-grade toolchains with the certification support that safety-critical industries require. The development of required tooling, like MC/DC coverage analysis, static analysis checkers, coding standards enforcement, safety-qualified compiler implementations, and certified runtime libraries, addresses the gaps that previously made Rust unsuitable for regulated environments.
The realistic path forward involves strategic replacement rather than wholesale migration. New projects and technology refreshes represent natural inflection points where the benefits of memory safety outweigh migration costs. Safety-critical industries are beginning to recognize that the additional upfront investment in Rust adoption pays dividends through reduced testing overhead, fewer field failures, and improved security posture.
Instead of asking whether Rust will replace C, we should ask whether we can afford not to adopt memory-safe alternatives where technically feasible. The answer increasingly appears to be no – making Rust adoption less a question of preference and more one of professional pragmatism.
Jonathan Pallant, Senior Embedded Systems Engineer at Ferrous Systems
C is a programming language with over 50 years of history. It was designed for writing tools and components for Unix, running on the minicomputers of the early 1970s. For that specific role – as the standard language of Unix and POSIX – C will remain supreme.
But for many other areas of software development where resource usage and performance are paramount, Rust’s ability to match the speed of C code while massively reducing development times will see it become the default systems programming language. And when someone writes the next Unix, they are most likely to do it in Rust.
For safety-critical systems, using Rust will come to be seen as the default – the lowest-risk option. This is because much of the verification and validation can be left-shifted into the toolchain (and the IDE) rather than left to the test department or expensive static analysis add-ons.
For CLI tools and cloud services, Rust is already replacing C and C++ – especially where performance really matters. The productivity benefits of having a standard build system and package manager without the run-time pain of programming in a language like Python are too good for most to ignore, not to mention achieving C-like levels of performance (or better) on top.
I think desktop applications are one area where Rust might struggle. Desktop applications need to tie closely with the operating system-supplied GUI toolkits – otherwise, you end up with Java Swing. These toolkits generally date back to the object-oriented programming boom of the mid-1990s and are not currently well-suited for use with Rust. But for embedded systems where integrating with pre-existing applications isn’t a requirement, Rust offers many advantages, especially on resource-constrained systems.
Finally, in education, I think Rust will become the default language for teaching programming at the university level. We have seen that the language around Rust and its ownership and borrowing model makes it easier to explain how C and C++ programs work, so learning Rust first makes a lot of sense.
Several universities are doing this already, especially in China, and I think we will see more make the switch. For pre-university education, I think Python will likely remain a better choice.
So, will Rust replace C? Yes, in many areas – but C will not go extinct. After all, C continued on after C++, and both Fortran and COBOL continued after C.
Ken Briodagh is a writer and editor with two decades of experience under his belt. He is in love with technology and if he had his druthers, he would beta test everything from shoe phones to flying cars. In previous lives, he’s been a short order cook, telemarketer, medical supply technician, mover of the bodies at a funeral home, pirate, poet, partial alliterist, parent, partner and pretender to various thrones. Most of his exploits are either exaggerated or blatantly false.