4 ms·

As an embedded dev, it still feels a decade away, at least. Rust is perfectly usable as a lang to make a little module that links into your main project as a .a

As an embedded dev, it still feels a decade away, at least. Rust is perfectly usable as a lang to make a little module that links into your main project as a .a file. But, as the language for your whole embedded codebase? Forget it. I have a litany of complaints including Cargo fuckery, ecosystem neglect, lack of first-party support, excessive code size, bad documentation, and bad IR that wastes stack by creating copies on immutable moves. Don't get me wrong, Rust is lightyears ahead of any other alleged C/C++ successor. But I work in a space where C and C++ have been the only option for the last 30 years with absolutely no production-ready alternative. It looks like that won't be changing anytime soon, which is disappointing.

afdbcreid 22d ago
Rust is already used in production for embedded (although only here and there). Not all places are ready, but I don't believe it's a decade away anymore.
- ryukoposting 19d ago
  It really depends what you count as "used in production." I don't count "one Rust library crate linked into your Zephyr/FreeRTOS/whatever project." I have yet to see any production bare-metal codebase written exclusively in Rust, at least at the kind of scale I deal with. If you're in the middle of a supply chain like I am, often times your code is actually a reference design that gets forked by an OEM, tweaked to their liking, and integrated into a product. If the OEMs don't know Rust, they aren't gonna like it if I start handing them Rust reference code. Spoiler alert: they don't know Rust! It goes the other way, too. A huge part of my job is working with drivers from Microchip, or Infineon, or Nordic, or whoever. They won't give me drivers in Rust. I could LLM my way out of that problem, but now I fully own my drivers with no first-party support, which is a huge step backwards from the current state of the art. This isn't Rust's fault, of course, but it means that there's a ton of inertia, and that magnifies the effects of the issues that are Rust's fault.
skavi 22d ago
All reasonable pain points. On the "Cargo fuckery" though, you might consider switching to an alternate build system like Bazel. Comes with its own set of issues (rustc isn't tied to Cargo, but the third party ecosystem definitely assumes it). But for embedded where you're cross compiling and working with C and C++ as well, I find it's a better solution than Cargo.
throwaway2037 21d ago
> But I work in a space where C and C++ have been the only option for the last 30 years with absolutely no production-ready alternative. What "space"? My guess: HFT or HPC.
- wrxd 21d ago
  Their message begins with "As an embedded dev"
  - tialaramex 21d ago
    "embedded" is very vague though. The problem is that both the guy writing PIC machine code for a $5 thermostat and the guy who wrote some Python running on the Linux box inside a Times Square moving advert think they're "an embedded dev".
    - cmrdporcupine 21d ago
      Regardless, neither HPC or HFT are "embedded"
    - ryukoposting 19d ago
      Fair, I shoulda been more clear. Explained in a sibling comment. Bare metal. That's the real embedded if you ask me ;)
- ryukoposting 19d ago
  Bare-metal embedded firmware for microcontrollers. Right now I do the EC that goes in your laptop. Making your fans spin, making your power button work, making your computer turn off if it gets too hot, stuff like that. Previously I've done firmware for bluetooth SOCs going into medical devices and little satcom doohickeys.
fullstop 21d ago
I'm in the same boat. Using Rust within Yocto is tricky since the whole point of Yocto is that you have a system which can build reproducible images. I can't have Cargo going out and fetching crates during the build process, they need to be recipes and artifacts which are accurately versioned and identified.
- tcfhgj 21d ago
  You don't have to use Cargo,you can fall back to just using rustc; also Cargo supports censoring, meaning you can use locally stored crates.

afdbcreid 22d ago

Rust is already used in production for embedded (although only here and there). Not all places are ready, but I don't believe it's a decade away anymore.

ryukoposting 19d ago
It really depends what you count as "used in production." I don't count "one Rust library crate linked into your Zephyr/FreeRTOS/whatever project." I have yet to see any production bare-metal codebase written exclusively in Rust, at least at the kind of scale I deal with. If you're in the middle of a supply chain like I am, often times your code is actually a reference design that gets forked by an OEM, tweaked to their liking, and integrated into a product. If the OEMs don't know Rust, they aren't gonna like it if I start handing them Rust reference code. Spoiler alert: they don't know Rust! It goes the other way, too. A huge part of my job is working with drivers from Microchip, or Infineon, or Nordic, or whoever. They won't give me drivers in Rust. I could LLM my way out of that problem, but now I fully own my drivers with no first-party support, which is a huge step backwards from the current state of the art. This isn't Rust's fault, of course, but it means that there's a ton of inertia, and that magnifies the effects of the issues that are Rust's fault.

skavi 22d ago

All reasonable pain points. On the "Cargo fuckery" though, you might consider switching to an alternate build system like Bazel. Comes with its own set of issues (rustc isn't tied to Cargo, but the third party ecosystem definitely assumes it). But for embedded where you're cross compiling and working with C and C++ as well, I find it's a better solution than Cargo.

throwaway2037 21d ago

> But I work in a space where C and C++ have been the only option for the last 30 years with absolutely no production-ready alternative. What "space"? My guess: HFT or HPC.

wrxd 21d ago
Their message begins with "As an embedded dev"
- tialaramex 21d ago
  "embedded" is very vague though. The problem is that both the guy writing PIC machine code for a $5 thermostat and the guy who wrote some Python running on the Linux box inside a Times Square moving advert think they're "an embedded dev".
  - cmrdporcupine 21d ago
    Regardless, neither HPC or HFT are "embedded"
  - ryukoposting 19d ago
    Fair, I shoulda been more clear. Explained in a sibling comment. Bare metal. That's the real embedded if you ask me ;)
ryukoposting 19d ago
Bare-metal embedded firmware for microcontrollers. Right now I do the EC that goes in your laptop. Making your fans spin, making your power button work, making your computer turn off if it gets too hot, stuff like that. Previously I've done firmware for bluetooth SOCs going into medical devices and little satcom doohickeys.

fullstop 21d ago

I'm in the same boat. Using Rust within Yocto is tricky since the whole point of Yocto is that you have a system which can build reproducible images. I can't have Cargo going out and fetching crates during the build process, they need to be recipes and artifacts which are accurately versioned and identified.

tcfhgj 21d ago
You don't have to use Cargo,you can fall back to just using rustc; also Cargo supports censoring, meaning you can use locally stored crates.