Google recently rewrote the firmware for protected virtual machines in its Android Virtualization Framework using the Rust programming language and wants you to do the same, assuming you deal with firmware.
In a write-up on Thursday, Android engineers Ivan Lozano and Dominik Maier dig into the technical details of replacing legacy C and C++ code with Rust.
“You’ll see how easy it is to boost security with drop-in Rust replacements, and we’ll even demonstrate how the Rust toolchain can handle specialized bare-metal targets,” said Lozano and Maier.
Easy is not a term commonly heard with regard to a programming language known for its steep learning curve.
Nor is it easy to get C and C++ developers to see the world with Rust-tinted lenses. Just last week, one of the maintainers of the Rust for Linux project - created to work Rust code into the C-based Linux kernel - stepped down, citing resistance from Linux kernel developers.
“Here’s the thing, you’re not going to force all of us to learn Rust,” said a Linux kernel contributor during a lively discussion earlier this year at a conference.
If your alternative is C++ then it removes the enormous burden of manually tracking lifetimes and doing manual memory management. C++ does have RAII which helps with that enormously but even then there are a gazillion footguns that Rust just doesn’t have - especially with the newer stuff like rvalue references, std::move, coroutines etc. It also saves you from C++'s dreaded undefined behaviour which is everywhere.
It has a very strong (and nicely designed) type system which gives an “if it compiles it works” kind of feel, similar to FP languages like Haskell (so they say anyway; I’ve not used it enough to know). The borrow checker strongly pushes you to write code in a style that somehow leads to less buggy code. More compiler errors, but much less debugging and fixing bugs.
The libraries and APIs are generally very well designed and nice to use. If you’ve ever used Dart or Go think how nice the standard library is compared to JavaScript or PHP. It took C++ like 2 decades to get
string::starts_withbut Rust started with it (and much more!).Fast by default.
Modern tooling. No project setup hassle.
It’s a value based language, not reference based. References are explicit unlike JavaScript, Java, C#, etc. This is much nicer and makes things like e.g. copying values a lot easier. JavaScript’s answer for ages was “serialise to JSON and back” which is crazy.
Downsides:
Slow compilation sometimes. I’d say it’s on par with C++ these days.
Async Rust is kind of a mess. They shipped an MVP and it’s still kind of hard to use and has unexpected footguns, which is a shame because sync Rust avoids footguns so well. Avoid async Rust if you can. Unfortunately sometimes you can’t.
Interop with C++ is somewhat painful because Rust doesn’t have move constructors.
Great language overall. Probably the best at the moment.
I disagree with 5.
I am an electronics engineer, so admittedly only ever worked with C and Python scripting (and not a programmer by any means) but I literally stopped learning rust for embedded because every single tooling setup step was wrong or failed for both chips I was testing out (NRF chip and an esp32-C3). Maybe only embedded rust was still a mess tooling-wise, but I have no use case for learning userspace rust first. It would just be a waste of my limited free time 😅
I just would like to learn from your experience.
I have a different background, can’t say I am developer but a coder who mainly do prototyping in short amount of time, and sometimes help out building microservices, backend stuffs. Go really fit the bill neatly for my job, so my first attempt jumping into the embedded world, as a hobbyist, was with TinyGo and found it completely different from userspace application development. To be honest, I did like it as a unified toolchain, but it was not yet that mature the time when I used it (I hope they are much better now) and I always had to go into the “machine” code file to find out things that should be documented better. That said, I was really happy when I got my head around multiplexed led array on the microbit, and even figured out how to drive a continuous rotation servo by timed highs and lows (TinyGo had no PWM support for microbit) for a car crusher, with an empty tissue box of course. Made my little one cry when he saw it the first time and thought his toy cars were crushed.
But when I got into more “serious” hobbyist realm, playing around with nRF52840, ESP32 and Cortex-M0, I found that Zephyr Project just feel right to me. Maybe because I am not a bare-metal magician by trade, I found the device tree concept so easy to understand and I managed to tune a DTS for ESP-EYE to use the correct address region for PSRAM, though I could only enable 4MB of it as I still couldn’t understand why there are 2 separated address regions for a total 8MB of PSRAM!
By pure coincidence, IoT became the next big thing for the company I work in, so I am thinking about getting more tools in my shed. I will definitely look into CircuitPython. Never learned Python before because I just don’t like it, without any objective reason I am afraid, but I reckon it is a great tool to build something really really quickly. Another language I want to learn, as you can tell, is Rust, because I can’t expect my colleagues to know Zephyr when FreeRTOS is just a much more popular choice. I think one day I will have to look into FreeRTOS again but wouldn’t hurt learning one more modern langauge that hopefully can do the trick easily.
However, with some initial digging, it scares me. From libraries and tutorials, one thing that bugs me is that it seems everyone has to do like
Peripherals::take().unwrap()and many other long chains of method calls ending with.unwrap(). I feel like the borrow-checker is not quite ready for memory mapped IO but assumes every pointer is allocated on the heap. I just feel worried that one day they will say “okay, we actually need a different compiler for embedded, just like TinyGo for Go”, and I have to relearn. Another thing that I don’t know yet is, it seems not so easy to get them onto the chip? If I understand correctly, some of the nRF and ESP32 are on tier-1 support so I suppose they will be the easier choices to get started. I am interested to know from your experience what was wrong in the equation?Thanks and my apologies for making it so long.
I think embedded Rust is simply really really new, and requires interacting with crusty C tools which is going to reduce reliability.
It’s also a little fragmented with people trying different things out (e.g. Embassy vs RTIC), and different chips getting different levels of support.
Totally different experience to desktop development.
I would add to the downside that it’s not the best programming language for game development, etc. There was some blog post about how troublesome is it to develop games using Rust due to some of the features that are good in other areas, like the whole concept of “immutable by default”.
I can also recommend D, if you want to deal with different issues, like the D Language Foundation fearing of change due to not wanting to deal with division from a new and incompatible version yet again, the GC being both a blessing and curse, if you want to go without a (tracing) GC you’ll need to go with a custom runtime that potentially missing many of its features, the attribute hell, etc.
The guy doesn’t know what he is talking about.
When someone is stating something like “best programming language”, you immediately know he’s fuck all and he’s trying to sell you something…