5 ms·

Say you have to develop an embedded project. Try dealing with Rust and its dependency hell as everything you do requires a million different packages.. Or, deve

Say you have to develop an embedded project. Try dealing with Rust and its dependency hell as everything you do requires a million different packages.. Or, develop me a driver that needs DMA.. How about a kernel allocator? Want to do that? Sure just wrap everything in "Unsafe"... So what is the point? Furthermore Rust programs link to libc ironically.

kbolino 2y ago
You're definitely not going to be linking to libc in a no_std environment, which is going to cover much (though not all) of embedded development. That will also remove some of the most bloated library dependencies from even being available to you in the first place, and of the rest, it will debloat a lot of them. Even if your embedded development is targeting a hosted platform with libstd available, whether you link libc will depend on whether you use libc. Thanks to its stable syscall ABI, you don't have to link anything on Linux. But most other similarly situated operating systems require you to link something, whether it be USER32.DLL/KERNEL32.DLL on Windows, libSystem*.dylib on macOS, or yes, libc*.so on (most of?) the BSDs and other UNIX systems. And when libc is not required by the platform, but you do need some of its functionality (either out of convenience or cross-platform compatibility), you can statically link it (including MSVCRT on Windows).
dralley 2y ago
All of that HAS been done in Rust. It's not that bad. It's actually quite good in many ways. #[no_std] is fairly unique to Rust.
- jdefr89 2y ago
  Yes it has and can be done with rust. But usually by writing “unsafe” code so what the hell is the point if the majority of the code isn’t gonna have the Rust memory guarantees it would normally have? Furthermore, not all MCUs have a Rust compiler or tool chain to use. C is the defacto standard. Not saying it cannot be done, just that I am not sure it’s worth the extra effort and overhead.
  - dralley 2y ago
    Entire kernels have been written in Rust with less than 10% unsafe code. The entire line of argument that "the majority of code" needs to be unsafe in such contexts is BS. Especially when the "Rust culture" suggests building safe abstractions on top of unsafe building blocks, which tends to keep the unsafe code pretty well-contained to a small section of the codebase. There's plenty of Rust frameworks for microcontroller programming (embassy, etc.) that don't involve much if any unsafe Rust at all.
    - jdefr89 2y ago
      Can you link me to a viable/real world kernel rewritten in Rust? One that supports modern hardware? I am not talking about implementing a toy kernel here.
      - Ar-Curunir 2y ago
        https://www.redox-os.org/ https://www.redox-os.org/
      - steveklabnik 2y ago
        This is closer to an RTOS, but since we're also talking about embedded, we wrote https://hubris.oxide.computer/ https://hubris.oxide.computer/ for use in our products. Kernel is about 3% unsafe code last I checked, which was just a few months ago.
jodrellblank 2y ago
> "Sure just wrap everything in "Unsafe"... So what is the point?" https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html : "You can take five actions in unsafe Rust that you can’t in safe Rust .. it’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked .. by requiring these five unsafe operations to be inside blocks annotated with unsafe you’ll know that any errors related to memory safety must be within an unsafe block. Keep unsafe blocks small; you’ll be thankful later when you investigate memory bugs."
- bluGill 2y ago
  You are confusing best practice for what is done all too often. Unsafe should be small blocks, but I've seen people put unsafe on everything even though it isn't needed thus making it hard to find where it is needed. I'm not a rust programmer, but I'm lead to believe that those people then do things that need unsafe - but a safe option not only exists but would have been easier to write.
  - School-Cotton 2y ago
    For very low-level stuff (e.g. embedded) you might need a lot of unsafe. For the vast majority of software it’s extremely rare. I worked full time for five years on a Rust project (https://github.com/MaterializeInc/materialize https://github.com/MaterializeInc/materialize) and anecdotally, unsafe code was much less than 1% of the codebase.
    - bluGill 2y ago
      I don't have direct experience, but from what I can gather between others, and my general embedded experience, unsafe in the worse case of embedded would still be just a small percentage of all code. (a device driver which would need unsafe to deal with hardware still has a lot of code that doesn't deal with hardware) There is some rust code out there that is more than 50% unsafe though.
  - 2y ago
0x457 2y ago
I'm current working on an embedded project in rust. The most annoying part is when the project is shared with a non-embedded part, but otherwise it's a breeze to work on. Had no issues using DMA or anything else.

kbolino 2y ago

You're definitely not going to be linking to libc in a no_std environment, which is going to cover much (though not all) of embedded development. That will also remove some of the most bloated library dependencies from even being available to you in the first place, and of the rest, it will debloat a lot of them. Even if your embedded development is targeting a hosted platform with libstd available, whether you link libc will depend on whether you use libc. Thanks to its stable syscall ABI, you don't have to link anything on Linux. But most other similarly situated operating systems require you to link something, whether it be USER32.DLL/KERNEL32.DLL on Windows, libSystem*.dylib on macOS, or yes, libc*.so on (most of?) the BSDs and other UNIX systems. And when libc is not required by the platform, but you do need some of its functionality (either out of convenience or cross-platform compatibility), you can statically link it (including MSVCRT on Windows).

dralley 2y ago

All of that HAS been done in Rust. It's not that bad. It's actually quite good in many ways. #[no_std] is fairly unique to Rust.

jdefr89 2y ago
Yes it has and can be done with rust. But usually by writing “unsafe” code so what the hell is the point if the majority of the code isn’t gonna have the Rust memory guarantees it would normally have? Furthermore, not all MCUs have a Rust compiler or tool chain to use. C is the defacto standard. Not saying it cannot be done, just that I am not sure it’s worth the extra effort and overhead.
- dralley 2y ago
  Entire kernels have been written in Rust with less than 10% unsafe code. The entire line of argument that "the majority of code" needs to be unsafe in such contexts is BS. Especially when the "Rust culture" suggests building safe abstractions on top of unsafe building blocks, which tends to keep the unsafe code pretty well-contained to a small section of the codebase. There's plenty of Rust frameworks for microcontroller programming (embassy, etc.) that don't involve much if any unsafe Rust at all.
  - jdefr89 2y ago
    Can you link me to a viable/real world kernel rewritten in Rust? One that supports modern hardware? I am not talking about implementing a toy kernel here.
    - Ar-Curunir 2y ago
      https://www.redox-os.org/ https://www.redox-os.org/
    - steveklabnik 2y ago
      This is closer to an RTOS, but since we're also talking about embedded, we wrote https://hubris.oxide.computer/ https://hubris.oxide.computer/ for use in our products. Kernel is about 3% unsafe code last I checked, which was just a few months ago.

jodrellblank 2y ago

> "Sure just wrap everything in "Unsafe"... So what is the point?" https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html : "You can take five actions in unsafe Rust that you can’t in safe Rust .. it’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked .. by requiring these five unsafe operations to be inside blocks annotated with unsafe you’ll know that any errors related to memory safety must be within an unsafe block. Keep unsafe blocks small; you’ll be thankful later when you investigate memory bugs."

bluGill 2y ago
You are confusing best practice for what is done all too often. Unsafe should be small blocks, but I've seen people put unsafe on everything even though it isn't needed thus making it hard to find where it is needed. I'm not a rust programmer, but I'm lead to believe that those people then do things that need unsafe - but a safe option not only exists but would have been easier to write.
- School-Cotton 2y ago
  For very low-level stuff (e.g. embedded) you might need a lot of unsafe. For the vast majority of software it’s extremely rare. I worked full time for five years on a Rust project (https://github.com/MaterializeInc/materialize https://github.com/MaterializeInc/materialize) and anecdotally, unsafe code was much less than 1% of the codebase.
  - bluGill 2y ago
    I don't have direct experience, but from what I can gather between others, and my general embedded experience, unsafe in the worse case of embedded would still be just a small percentage of all code. (a device driver which would need unsafe to deal with hardware still has a lot of code that doesn't deal with hardware) There is some rust code out there that is more than 50% unsafe though.
- 2y ago

0x457 2y ago

I'm current working on an embedded project in rust. The most annoying part is when the project is shared with a non-embedded part, but otherwise it's a breeze to work on. Had no issues using DMA or anything else.