←back to thread

Embedded Rust in Production?

(blog.lohr.dev)
205 points michidk | 5 comments | 14 Oct 24 06:06 UTC | HN request time: 0.706s | source
Show context
dextrous ◴[14 Oct 24 12:13 UTC] No.41836789[source]▶
I am a C/C++ dev learning Rust on my own, and enjoying it. I am finally starting to enjoy the jiu jitsu match with the compiler/borrow-checker and the warm “my code is safe” afterglow … but I have a question for the more experienced Rust devs out there, particularly in light of the OP’s observation about “lots of unsafe” in the Rust embedded realm (which makes sense).

If your Rust project leans heavily on unsafe code and/or many libraries that use lots of unsafe, then aren’t you fooling yourself to some degree; i.e. trusting that the unsafe code you write or that written by the 10 other people who wrote the unsafe libs you’re using is ok? Seems like that tosses some cold water on the warm afterglow.

replies(3): >>41836851 #>>41836872 #>>41846831 #
1. danhau ◴[14 Oct 24 12:23 UTC] No.41836851[source]▶
Yes, safe Rust is only as safe as the underlying unsafe code is.

The power of unsafe is that it‘s opt-in, making the surface area of „dangerous“ code smaller, more visible and easier to reason about.

As long as the unsafe parts are safe, you can rest assured that the safe parts will be safe too.

replies(2): >>41837019 #>>41839052 #
2. iTokio ◴[14 Oct 24 12:46 UTC] No.41837019[source]▶
Another way to see the benefit of this approach is that if you have a memory violation, then you only have to look in the unsafe blocks.

So, yes the less numerous they are, the more you gain from it.

replies(1): >>41843936 #
3. throwawaymaths ◴[14 Oct 24 16:26 UTC] No.41839052[source]▶
> As long as the unsafe parts are safe, you can rest assured that the safe parts will be safe too.

That is not true. It is possible to have two pieces of validated unsafe code that are "safe" in isolation but when you use them in the same codebase, create something unsafe. This is especially true in embedded contexts, where you are often writing code that touches fixed memory offsets, and other shared globals like peripherals.

replies(1): >>41843178 #
4. tialaramex ◴[14 Oct 24 23:10 UTC] No.41843178[source]▶
In some cases you might have the excuse that, well, you did say on the tin not to do this with the unsafe element. For example if I use Bob's "I need exclusive control of GPIOs 2, 3 and 6" and also Kate's "I need exclusive control of GPIOs 1, 2 and 4" unsafe code, then it's my fault, they did both tell me this requirement and they clash.

But in general this is specifically a bug in the unsafe code. The Rustonomican is very clear that it's not the safe code's fault that your unsafe code doesn't work. In the scenarios with conflicting libraries I guess it's the fault of somebody who linked conflicting libraries, but it's definitely never the safe code.

5. inahga ◴[15 Oct 24 01:11 UTC] No.41843936[source]▶
> Another way to see the benefit of this approach is that if you have a memory violation, then you only have to look in the unsafe blocks.

Not really. Safety is non-local. It is possible to break unsafe code by feeding inputs from safe Rust that don't uphold the invariants that make the unsafe code safe. So it's not enough to look in the unsafe blocks--you have to consider the all the contexts that invoke the unsafe code.

See https://doc.rust-lang.org/nomicon/working-with-unsafe.html, and https://notgull.net/cautionary-unsafe-tale/ for a practical example.