Hacker News Reader

Comment by the__alchemist | Hacker News Reader

Rust slaps on embedded too; I think that's one of its core competencies. But you have to do a lot of leg work for each piece of hardware because manufacturer support isn't there, and the OSS libs are usually not great. If your requirement is "Use only the most popular language in this domain", that's fine, but there's no point in evaluating or discussing other languages if so; the outcome is predetermined.

I think the linked requirement, the hype you see, and rust's own material is misleading: It's not a memory-safety one-trick lang; it's a nice overall lang and tool set.

View on HN

The unfortunate reality is that you must write almost all of your drivers from scratch if you want to rust in embedded. There is no OEM driver support, and as you said the open source drivers are all crap and written for arduino-level hobby projects.

Lack of drivers is prohibitive if your are a small/medium team or are using a lot of complicated peripherals or SoC. Compare to C where any MCU or embedded SoC or moderately complex peripheral normally comes with C driver code.

I'm not following: Rust excels at C interop, so why wouldn't you use the OEM drivers/SDK and bind them through Rust for your own code? That's what I've always done when I need to interact with a C library in Rust.

So the main reason that doesn't work sometimes is how you are using Rust. For instance right now I'm leaning into the Rust Embassy ecosystem which is async based, the drivers need relatively deep integration with the embedded-hal-async layer which is far from trivial to do with C bindings.

In practice I end up rewriting drivers. Which sounds daunting but often times it's much easier than folks think and the resulting code is usually 1/4th or smaller the original C code. If only implement what you need sometimes drivers can be less than 100 lines of Rust.

That's a scenario I hadn't considered, thanks!

Hmm. You raise a good point. I've been doing a bit of C FFI on std-rust applications, but hadn't thought to apply this to embedded much. I have wrapped CMSIS-DSP (ARM-official DSP toolkit; filters etc) with Rust embedded, and it works out well! Increases compile times, but worth it. Perhaps we should apply this approach more broadly.

One problem: It's tedious going from the pointer-level API bindgen gives you to a high-level rust API that has references, arrays etc. In that you have to do some boilerplate for each bit of functionality you want. Not a big deal for a specific application, but not ideal if making a general library. And C libs tend to be sloppy with integer types, which works, but is not really idiomatic for rust. Maybe that could be automated with codegen or proc macros?

I believe the ESP-IDF rust lib is mostly FFI (?); maybe that's a good example. We've been re-inventing the wheel re STM-32 and Nordic support.

> I'm not following: Rust excels at C interop

Zig is an example of excelling at C interop--not Rust.

And Cargo is an impediment in the embedded ecosystem rather than a bonus.

Part of why we're getting Rewrite-it-in-Rust everywhere is precisely because the C interop is sufficiently weak that you can't do things easily in a piecemeal fashion.

And lets not talk about Rust compile times and looking at Rust code in a debugger and just how bad Rust code is in debug mode ...

I don't have strong opinions in either direction about Zig. But there's clear empirical evidence that Rust has a successful C interop story[1][2][3].

And note: browsers are the pathological case, in terms of build system integrations, global state assumptions, C++, etc.

(Your other complaints have a place, and don't seem unreasonable to me. But they're empirically not impediments to Rust's interop story.)

[1]: https://chromium.googlesource.com/chromium/src/+/refs/heads/...

[2]: https://firefox-source-docs.mozilla.org/build/buildsystem/ru...

[3]: https://www.memorysafety.org/blog/rustls-nginx-compatibility...

Reply on news.ycombinator.com