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.
I’ve only barely scratched the surface there myself but, I absolutely do think so. For several reasons. First, ESP32 is one of the few series of MCUs that support the Rust stdlib. And learning what that entails for Rust is extremely helpful in conceptualizing build targets. Second, MCUs are a very constrained target for software/firmware. Getting comfortable there will likely improve your code efficiency in other code platforms as you are more likely to think about resource usage earlier. And third, there’s some pretty excellent docs and tutorials.
For tutorials, my recommended starting point is with the official docs/books themselves:
deleted by creator
I/O and logic for an MCU. The hardest bits, TBH, are already done with the ESP32 series MCUs, thanks to the efforts to get the Rust stdlib and HAL supported. So, the experience, code-wise, isn’t much different from Arduino or Micro/CircuitPython. Mostly, it’s down to syntax, flashing toolchain, and logic.
So, the experience is likely to be similar to development on with a full-fledged CPU/SoC target. I’d suggest that the experience of developing for an MCU, regardless of language, is likely to put one up against constraints that will make them think more about resource management considerations when approaching other target platforms.