Hacker News Reader

Comment by baby | Hacker News Reader

I'm very interested with Rust on Embedded Devices. I've recently ported my cryptographic library (www.embeddedDisco.com) to C, thinking it was the only way to support these many tiny systems, but it looks like it might become less and less true. I'm still wondering, how are young developers using something like the Arduino IDE supposed to figure out how to use a Rust library.

View on HN

Arduino has the benefit of several years of refinement and an all-in-one, multi-target library. Embedded Rust is still in its infancy, though it's absolutely usable and (imo) practical for experienced users. I think as the embedded abstractions get polished and there is more convergence of HALs, something like an all-inclusive solution may come about. As it stands, it's very easy to combine a chip HAL and device drivers, but you have to know what building blocks to grab (if they're there - there's lots to be done!).

This is what most interests me about Rust, using it to replace the C code on our embedded devices. Nice to see that is a first class use case now and the language will be mainted to ensure it is supported.

I might have to try and do a proof of concept with one of our devices now :)

To add on to what jamesmunns has already said, we're an excited group, us embedded Rust users. I recently built one of our in-house products using Rust as a proof-of-concept, and the process convinced me that Rust is the future of embedded devices. Feel free to reach out to me if you have any questions. I'd love to keep working with embedded Rust!

Hey! Feel free to check out what we have going on at https://github.com/rust-embedded/wg, and our docs with getting started guides at https://docs.rust-embedded.org!

I wonder if there any compiles-to-C languages will "port" compilers to create compiles-to-Rust versions. Because there are plenty of those languages out there in the embedded space.

Nim to Rust is on the roadmap.

What would be the advantage?

Probably none I'd guess. The embedded space really loves C simply because it's viewed (usually wrongly) as more deterministic than C++ but there are a lot of instances where C is not a good choice (when you no-shit need objects) so they come up with abstractions for common things (terrifying C patterns). Rust has a lot of features that C lacks so we probably won't need to do any abstraction for now.

Why do you say none, then immediately list a few advantages of Rust? To build on your points:

- it might be a easier language to target with a compiler because it's a higher-level intermediate language

- there would be fewer undefined behavior shenanigans

- successfully writing a compiler that targets Rust without using unsafe (too much) would mean getting (some of) the safety benefits as a side-effect. Could especially be relevant for languages aiming to introduce zero-overhead safety to the embedded environment themselves

- regarding previous point: discovering bugs in the process of porting to Rust

- because Rust plays relatively nicely with C and C++, one wouldn't have to lose existing libraries along the way

I'm saying "None" in response to needing compilers that compile to Rust, not to rust itself. Basically to boil down my argument, we don't need to compile to Rust instead of C because simply replacing C with Rust should be sufficient. People made "compiles to C" languages because C was not capable of doing everything they wanted easily.

Aaah, I see where you are coming from. Yes, that is a good point.

Porting a compiler could still be useful for the sake of legacy code though.

It seems to me that writing a compiler that can target safe rust would be extremely hard with little benefit.

Not only that, they also love to deploy with optimizations turned off to avoid any compiler magic, so you end up with some convoluted hand written code, which could otherwise be written by the compiler itself.

Easier interop with Rust crates?

Compile times might be pretty painful with that kind if setup...

Reply on news.ycombinator.com