Enabling Rust on Embedded Platforms – Linux, RTOS, Bare Metal
In this technical retrospective (2017), @ingve shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Cloud & Mobile Era (2014–2019)
COMMUNITY SCORE 235 points
TOTAL DISCUSSIONS 50 comments
I took a look at the gpio code, just to see what Rust for embedded would look like.
I did't like the noise due obrigatory use of unwrap() after calling a function with constants (such as constructing a regex). Such setup obviously must panic when it fails.
Also, Rust seems to be missing a way to "clean out the parent scope", by saying something like:
``` let Some(a) = check(param0) && let Some(b) = check(param1) else { return Err("Illegal arguments"); }
``` Here 'a' and 'b' would be created in the parent scope, not in the body as in the 'if let' statement.
Note that both criticisms revolve around introducing a concept of failure in the type system. Maybe the last member of a type could correspond to "failure" by default (ie None or Err() in typical cases).
I have been recently learning Rust and like its super powers. The above observations worry me in the sense that error handling is quite central to clean and readable code, and because Rust seems to promote the nesting of the main path, which, at least to me, is an anti-pattern.
Please correct me if I'm wrong.
For being able to run Rust on Bare Metal I thoroughly enjoyed Philipp Opperman's blog series. [0]
Although admittedly I only used his assembler tips so I was able to create a minimal kernel to test for VMware's new desktop requirements on Workstation 14/Fusion 10 where a CPU has to have "VMX Unrestricted Guest" support for their product to be able to run VMs.
Thanks to his blog I was able to create a small bootable cd image to test for Unrestricted Guest features on intel CPUs. [1]
Finally if you want to see Rust as an OS, it already exists! Have a look at Redox [2]
[0] https://os.phil-opp.com/multiboot-kernel/ ↗
[1] https://communities.vmware.com/message/2709089#2709089 ↗
[2] https://www.redox-os.org/ ↗
I've been using japaric's awesome work on Xargo (for cross compiling the std lib) to target a variety of ARM Cortex'es. Sometimes doing all work in Rust, sometimes just for linking against Rust crates in a C program. It's a breeze and super fun.
This is, in my opinion, where Rust really shines: using one codebase - without installing any new tools - I can target pretty much all platforms from embedded to browser to mobile.
For rust on bare metal target, it is also worth looking at: http://blog.japaric.io/quickstart/ ↗ and other work by Jorge Aparicio - https://github.com/japaric ↗.
Is anyone else concerned about Rust’s handling of heap allocation failures? Right now the existing APIs for heap allocation are built pretty deep into the language and they all panic on failure. It’s one thing for Firefox to crash when my computer completely runs out of swap, but another for Linux to panic when it’s out of heap space.