Comment by ryukoposting
18 hours ago
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.
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.
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.
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.
What "space"? My guess: HFT or HPC.
Their message begins with "As an embedded dev"
"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".
1 reply →