A decent question, I've wondered about Rust programs on openwrt but at the moment they're just too big! Linking the stdlib into every binary doesn't help, and the code is generally larger than the C equivalent. It doesn't seem unsolvable though, I'm hopeful. no_std rust binaries can be near competitive with C.
Binary size is sometimes a big deal. Two decades ago I investigated using C++ for an "embedded" linux ssh server, but decided the 30kB overhead was too large (target was a 4MB laptop). The server ended up being used in OpenWRT and other places, I'm curious if it would have happened if I'd gone with C++ instead.
This is on point. I work on small-ish embedded Linux systems and I would really like to use Rust there, but a single Rust binary takes up enough space for 10 C programs, so it's prohibitive. You can dynamically link your libraries (especially since these systems are usually built as full images, so ABI compatibility does not really matter) and it helps a little, but nowhere close to the order of magnitude you need.
Alas, there is little interest in/awareness of the middle ground between the no_std world and the "size doesn't matter" world in the Rust community right now. I've asked a bunch of people for pointers as to where to start working towards supporting those cases but I mainly got shrugs. There were attempts at more lightweight stdlibs and so on, but they all seem to have fizzled out.
I wonder how much of this is inherent in the language design. Rust heavily leans on monomorphization, so as a first approximation, you will always generate more code (before maybe optimizing that away again). Famously, the Swift people went to great lengths to avoid these problems: https://faultlore.com/blah/swift-abi/. But while running Swift on Linux is possible, this is even more niche.
totally agree,that's the same reason I gave up rust for embedded systems, beyond no_stb bare metal use case,it is way too big in size comparing to c and c++.
golang has similar size issue,sadly.
I used Rust on an attiny22 to decode standard 433MHz remote radio packets. It is little 8bit microcontroller with 256 bytes of RAM and enough flash to store about 1024 instructions.
The key was to turn off panic unwinding, turn on size optimization, and full LTO. I think I recall increasing the inlining threshold helped a bit.
https://github.com/mkj/sunset/tree/main/embassy/demos/picow is a wifi-ssh to serial impl for a rp2040. I've got it plugged into my home server's serial port. It's using cyw43 for wifi also from Embassy - dirbaio is prolific! There's some WIP in Embassy for bluetooth.
That repo has a few crates depending on each other - sunset is the toplevel ssh, sunset-embassy adds no_std async, then the async dir has std rust, with a commandline ssh client in the examples dir.
Actually I'm often surprised just how much out there is actually available with no_std feature options?
There's obviously a lot of need for improvement in Rust in regards to small systems, as people have pointed out. But there's also a lot more middle ground in Rust vs, say, C++: You can be no_std and still have Vector, for example, while in C++ the STL is an all-or-nothing thing.
It's a smaller community, and it will come down to individuals deciding it's important and making contributions.
> Linking the stdlib into every binary doesn't help
It should be possible to use a shared library for std but it would come with the limitation that the bins must be compiled with exactly the same rustc as std.
Binary size is sometimes a big deal. Two decades ago I investigated using C++ for an "embedded" linux ssh server, but decided the 30kB overhead was too large (target was a 4MB laptop). The server ended up being used in OpenWRT and other places, I'm curious if it would have happened if I'd gone with C++ instead.