Wait, are you implying that code written in Rust somehow "rusts"?
Code in all languages bitrots. Even if your dependencies are "done", the language is unchanging, the toolchain mature, a vendor can introduce a new platform and all of a sudden your code won't compile anymore, because IBM introduced a new RISC server platform, or macOS changed the definition of time_t, or Windows blocked direct win32.DLL access (I know, a stretch), that your older libraries didn't know about.
> Rust is evolving far too fast to be used in code which needs to run for years to decades down the line. Code doesn’t stop running on existing hardware when the language changes in a future compiler. You can still use the same old toolchain. I’ve done a lot of embedded development in a past life. Keeping old tool chains around for each old platform was standard. I would much rather go through the easy process of swi…
I remember a coworker having to fight with an old platform's build not working because our user/group IDs were bigger than 2^16. I can't remember which utility was causing the problem, I'd have to guess tar. This is when we learned to play the archive a VM game.
I can't imagine theres much overlap between "we will need to update this firmware for the next decade." and "Let's bet the farm on the documentation being perfect, and all the downloads still available."
This is not a Rust issue but an inherent issue with dependencies in all languages. External dependencies rot. For Rust code for serious industrial use cases or firmwares, it's always best to minimize dependencies as much as possible to avoid this. Making local copies of dependencies is also a thing for certain use cases.
There is a difference in C and Rust culture. Embedded C projects rarely have external dependencies, and in rare cases when there are dependencies (e.g. most projects use vendor SDKs nowadays), they are pinned and there is an expectation of API compatibility anyway Rust on the contrary incentivises using dependencies, and especially embedded software is hard to write without using external packages (e.g. cortex-m-rt,…
We passed on Rust for Ada/SPARK2014 to write to bare metal on Cortex-M processor for real-time, high-integrity, and verifiable mission-critical software. Rust is making strides to be a future competitor, but it's new to the formal verification tooling and lacks any real world legacy in our domain. Ada's latest spec. is 2022. Other than AdaCore's verified Rust compiler, Rust still does not have a stable language specification like C/C++, Lisp, or Ada, SPARK 2014. I have no doubt that it will start rising to tick all the boxes that Ada/SPARK do right now with their decades of legacy in high-intetrity, mission-critical applications. The mandate to use memory-safe software put into effect this past Jan 1 2026 puts some wind in Rust's sails, but it's more than memory-safety in this domain. Plus, I do not enjoy Rust, but Cargo is nice. We're looking at Lean for further assistance in verifying our work. I think there was and is lot of Rust evangelism that will also carry it forward and boost even more Rust popularity,
> It is concluded that Rust is a sound choice today for firmware development in this domain. This conclusion was reached with a single experiment. > Two teams concurrently developing the same functionality — one in C, one in Rust — are analyzed over a period of several months. > Furthermore, Ariel OS is shown to provide an efficient and portable system runtime in Rust whose footprint is smaller than that of the state…
> This conclusion was reached with a single experiment.
No shit. This is the conclusion reached at the conclusion of this experiment. This part of your comment can be removed with no loss of clarity, I think.
We passed on Rust for Ada/SPARK2014 to write to bare metal on Cortex-M processor for real-time, high-integrity, and verifiable mission-critical software. Rust is making strides to be a future competitor, but it's new to the formal verification tooling and lacks any real world legacy in our domain. Ada's latest spec. is 2022. Other than AdaCore's verified Rust compiler, Rust still does not have a stable language speci…
Presumably, if you use formal verification then that includes memory safety anyway? Would seem strange if it does not.
> It is concluded that Rust is a sound choice today for firmware development in this domain. This conclusion was reached with a single experiment. > Two teams concurrently developing the same functionality — one in C, one in Rust — are analyzed over a period of several months. > Furthermore, Ariel OS is shown to provide an efficient and portable system runtime in Rust whose footprint is smaller than that of the state…
> In Figure 12, they simply stop optimizing the code once desired rate is reached.
Yes. The goal was to handle the maximum data rate of the used sensor, and stop there. Time was limited on both ends.
> Just at the end of the project the Rust firmware gets over a third performance boost, most likely from their OS developers.
The ST intern found those boosts all by himself. They compared the exact MCU & peripheral initialization of the C and Rust firmwares, tightened I2C timings (where STM Cube has vendor tuned & qualified values), and enabled the MCU's instruction cache, which somehow is not default in Embassy's HAL. We were quite impressed actually, the last days before the deadline were quite productive, optimization wise.
Authors are from STMicro, polytechnic Turin, Freie universitat Berlin, and Inria. Examined writing firmware for an IOT sensor platform. From the abstract: > Two teams concurrently developing the same functionality (one in C, one in Rust) are analyzed over a period of several months. A comparative analysis of their approaches, results, and iterative efforts is provided. The analysis and measurements on hardware indica…
[flagged]
Rust uses "Editions" (e.g., 2015, 2018, 2021, 2024) to introduce breaking changes without splitting the ecosystem. Every edition remains supported by newer compiler versions _indefinitely_. The only churn is on projects targeting "nightlies" but there's no reason you can't target a stable one for projects that need that stability.
I only tried Rust for small hobby projects, but I did experience weird code rot when you just leave the code there and after a while it does not compile. Might have something to do with how Cargo manages dependencies
Do you remember more specifics? I've seen four cases: - a project with no Cargo.lock, where there have been breaking changes in a dependency that wasn't specific enough in Cargo.toml; fixing this requires some finessing of dependencies but is possible to get the project building without any code changes - a project with proper dependency tree specified, but where a std change cause inference to break specific older v…
I'd add pinning a rust toolchain version (using rust-toolchain.toml or similar) in addition to Cargo.lock
Rustc does have fairly frequent (every ~18 months of so) minor breaking changes between versions. These are often related to type inference, usually only affect a very small number of crates, and are usually mitigated by publishing patch versions of those crates that don't run into the issue. But if you have the patch version locked with a lockfile then that won't help you, and there is increased likelihood of the build failing, so it's best to lock down the rustc version too.
Luckily pinning the rustc version is very easy to do.
---
On regular projects this kind of issue can usually also be fixed by upgrading to the latest rustc and running `cargo update`. But conservative embedded projects may have legitimate reasons for not wanting to upgrade rustc to the latest version, and parts of ecosystem's disregard for MSRVs means that running `cargo update` on an older rustc has a high chance of causing build breakage due to MSRV issues.
> It is concluded that Rust is a sound choice today for firmware development in this domain. This conclusion was reached with a single experiment. > Two teams concurrently developing the same functionality — one in C, one in Rust — are analyzed over a period of several months. > Furthermore, Ariel OS is shown to provide an efficient and portable system runtime in Rust whose footprint is smaller than that of the state…
> This conclusion was reached with a single experiment. No shit. This is the conclusion reached at the conclusion of this experiment. This part of your comment can be removed with no loss of clarity, I think.
I think you miss my point. I don't think that this conclusion can be reached with the (singular) experiments performed because there is a lack of data to draw it.
If I ran an experiment where I gave a cancer patient bread, and then they recovered from cancer, I couldn't then say: "It is concluded that is a sound choice today for in this domain.". You would rightfully jump up and down and demand further experiments to increase the confidence of the result before drawing the conclusion.
It could have been concluded instead that there is a case for further experiments to be conducted, or that Rust could be approaching a maturity where it could be considered for some firmware projects. But as it stands, the conclusion is far too strong given the experiments performed.