4 ms·

There are some issues I have with using Rust for bare metal work: - “zero cost” abstractions end up compiling to lots of code/code that does weird things that

There are some issues I have with using Rust for bare metal work: - “zero cost” abstractions end up compiling to lots of code/code that does weird things that can cause cashe thrashing and/or pipeline misprediction. In C the cost of everything is very explicit, in Rust it’s very easy to end up with an inefficient binary. The low correspondence between Rust/C++ and machine code is unattractive when doing bare metal work. - unsafe blocks seem to defeat the purpose of Rust. It’s like building a proof on top of lemmas that are just random guesses. - Clean builds of my test project are very slow.

DominikD 7y ago
1. There are no zero cost abstractions. But Rust ones are as close to zero as possible. You may not want to pay for these on the smallest Cortex M devices but I would sure take them over the pain that is debugging C code on stuff like TM4C123G. 2. That's not correct. Board support packages have some unsafe code in them, sure, but it's a misconception that this defeats the purpose of Rust. Even unsafe code has to uphold borrow checker semantics. Unsafe doesn't turn them off, you can't take two mutable references to the same variable in unsafe block, it won't compile. But you can use raw pointers and it's developer's job to make sure that pointer math is correct. This way your application code calling these low level bits of unsafe code doesn't have to do anything to benefit from the regular Rust guarantees. It's a "make things correct once, benefit always" sort of a deal. 3. In general Rust build times aren't great but I can't say they are worse than working with TI's CCS. Extended compile times on desktop are noticeable but I can't say this is true to the same extent on bare metal.
- wahern 7y ago
  > you can't take two mutable references to the same variable in unsafe block, Huh? Creating multiple, unchecked mutable references to the same object is one of the few reasons to even use unsafe. If you get this wrong, Rust's type safety won't save you--any bug effectively undermines the integrity of the remainder of the program. Of course, that doesn't negate the benefits of Rust's type safety, or mean that any program using unsafe is no better than a C or C++ project.
  - steveklabnik 7y ago
    Usually, "mutable reference" refers to &mut T. "mutable pointer" refers to *mut T. Creating aliasing &mut Ts is UB, even in an unsafe block. Sometimes people are not precise about these words, but that's how I read the parent, given they drew the distinction between "mutable reference"s and "raw pointers".
    - DominikD 7y ago
      Thank you, this is exactly what I meant.
cyphar 7y ago
> In C the cost of everything is very explicit, in Rust it’s very easy to end up with an inefficient binary. I will admit when I first picked up Rust, I struggled with feeling as though the code I was writing was too abstract and I had no idea what the compiled code would look like. But if you actually look at the performance characteristics of things such as Rust's default hashmap you find it's more efficient than most hashmaps in C code (because AVL trees are easier to write correctly in C, but B trees are faster and in Rust users can be sure they're using them safely). > unsafe blocks seem to defeat the purpose of Rust. It’s like building a proof on top of lemmas that are just random guesses. Not really, (using your analogy) unsafe blocks are more like human-checked proofs while everything else is machine-checked proofs. Obviously the humans doing the checking of the unsafe blocks can make mistakes (hence why you should minimise it), but unsafe blocks still must obey Rust's memory model. > Clean builds of my test project are very slow. Yeah that is still a noticeable problem. But to their credit, they have been slowly improving compile times for several years now.
- tick_tock_tick 7y ago
  For the first point it's more that a single instance of panic! in your code will balloon your binary size
  - cyphar 7y ago
    Am I missing something -- shouldn't "panic = <some_c_func>" (in Cargo.toml) solve that problem?

DominikD 7y ago

1. There are no zero cost abstractions. But Rust ones are as close to zero as possible. You may not want to pay for these on the smallest Cortex M devices but I would sure take them over the pain that is debugging C code on stuff like TM4C123G. 2. That's not correct. Board support packages have some unsafe code in them, sure, but it's a misconception that this defeats the purpose of Rust. Even unsafe code has to uphold borrow checker semantics. Unsafe doesn't turn them off, you can't take two mutable references to the same variable in unsafe block, it won't compile. But you can use raw pointers and it's developer's job to make sure that pointer math is correct. This way your application code calling these low level bits of unsafe code doesn't have to do anything to benefit from the regular Rust guarantees. It's a "make things correct once, benefit always" sort of a deal. 3. In general Rust build times aren't great but I can't say they are worse than working with TI's CCS. Extended compile times on desktop are noticeable but I can't say this is true to the same extent on bare metal.

wahern 7y ago
> you can't take two mutable references to the same variable in unsafe block, Huh? Creating multiple, unchecked mutable references to the same object is one of the few reasons to even use unsafe. If you get this wrong, Rust's type safety won't save you--any bug effectively undermines the integrity of the remainder of the program. Of course, that doesn't negate the benefits of Rust's type safety, or mean that any program using unsafe is no better than a C or C++ project.
- steveklabnik 7y ago
  Usually, "mutable reference" refers to &mut T. "mutable pointer" refers to *mut T. Creating aliasing &mut Ts is UB, even in an unsafe block. Sometimes people are not precise about these words, but that's how I read the parent, given they drew the distinction between "mutable reference"s and "raw pointers".
  - DominikD 7y ago
    Thank you, this is exactly what I meant.

cyphar 7y ago

> In C the cost of everything is very explicit, in Rust it’s very easy to end up with an inefficient binary. I will admit when I first picked up Rust, I struggled with feeling as though the code I was writing was too abstract and I had no idea what the compiled code would look like. But if you actually look at the performance characteristics of things such as Rust's default hashmap you find it's more efficient than most hashmaps in C code (because AVL trees are easier to write correctly in C, but B trees are faster and in Rust users can be sure they're using them safely). > unsafe blocks seem to defeat the purpose of Rust. It’s like building a proof on top of lemmas that are just random guesses. Not really, (using your analogy) unsafe blocks are more like human-checked proofs while everything else is machine-checked proofs. Obviously the humans doing the checking of the unsafe blocks can make mistakes (hence why you should minimise it), but unsafe blocks still must obey Rust's memory model. > Clean builds of my test project are very slow. Yeah that is still a noticeable problem. But to their credit, they have been slowly improving compile times for several years now.

tick_tock_tick 7y ago
For the first point it's more that a single instance of panic! in your code will balloon your binary size
- cyphar 7y ago
  Am I missing something -- shouldn't "panic = <some_c_func>" (in Cargo.toml) solve that problem?