4 ms·

I fail to see how a borrow checker can even be remotely useful when there is only one kind of lifetime for everything: until the power to the device is shut off

I fail to see how a borrow checker can even be remotely useful when there is only one kind of lifetime for everything: until the power to the device is shut off. The only memory-related issues you can have then are out of bounds accesses and using uninitialized or stale data.

tptacek 7y ago
I don't know why we're arguing about the utility of the borrow checker in static memory systems since the borrow checker is obviously not the only difference between Rust and C in that setting; we talk about Rust in embedded systems because it doesn't have a heavyweight runtime that requires (in practice) garbage collection to function, and so is suitable for environments where Java and Go aren't tenable.
- gmueckl 7y ago
  We are not arguing these points because they were not brought up and do not really distinguish rust from other system languages.
cortesoft 7y ago
What are you talking about? You can certainly have memory related errors on an embedded system.... and the lifetime of memory can often be shorter than the full on cycle of the device.... you can use memory within a function that is not needed outside of it, etc. Borrow checking is unrelated to whether you are on an embedded device or not.
- gmueckl 7y ago
  If you need reliability and long uptime in an embedded device, dynamic memory management is shunned because it is detrimental to both. The probability of fatal memory fragmentation from bad allocation patterns is too high.
dralley 7y ago
Session types. Managing hardware state via the type itself, such that it is not possible to create code that does something with (e.g. an IO pin) unless it has first been properly set up, and it's guaranteed at compile time with no runtime checks. Guarding against mutable aliasing with respect to hardware state could be enormously valuable.
- gmueckl 7y ago
  How is a solution using a session type different from what you get with a C++ object with a constructor? I don't quite understand what you are saying in your second paragraph.
pcwalton 7y ago
This is a misunderstanding of how Rust's borrow check works. It is necessary for avoiding numerous memory safety issues, not just use after free. For example: let mut x: Result<i32,f32> = Ok(1); let y = x.as_ref().unwrap(); x = Err(1.0); println!("{}", y); // unsafe cast of float to int This issue was first described to my knowledge by Dan Grossman in "Existential Types for Imperative Languages". The context was trying to make unions work in a safe dialect of C (Cyclone).

tptacek 7y ago

I don't know why we're arguing about the utility of the borrow checker in static memory systems since the borrow checker is obviously not the only difference between Rust and C in that setting; we talk about Rust in embedded systems because it doesn't have a heavyweight runtime that requires (in practice) garbage collection to function, and so is suitable for environments where Java and Go aren't tenable.

gmueckl 7y ago
We are not arguing these points because they were not brought up and do not really distinguish rust from other system languages.

cortesoft 7y ago

What are you talking about? You can certainly have memory related errors on an embedded system.... and the lifetime of memory can often be shorter than the full on cycle of the device.... you can use memory within a function that is not needed outside of it, etc. Borrow checking is unrelated to whether you are on an embedded device or not.

gmueckl 7y ago
If you need reliability and long uptime in an embedded device, dynamic memory management is shunned because it is detrimental to both. The probability of fatal memory fragmentation from bad allocation patterns is too high.

dralley 7y ago

Session types. Managing hardware state via the type itself, such that it is not possible to create code that does something with (e.g. an IO pin) unless it has first been properly set up, and it's guaranteed at compile time with no runtime checks. Guarding against mutable aliasing with respect to hardware state could be enormously valuable.

gmueckl 7y ago
How is a solution using a session type different from what you get with a C++ object with a constructor? I don't quite understand what you are saying in your second paragraph.

pcwalton 7y ago

This is a misunderstanding of how Rust's borrow check works. It is necessary for avoiding numerous memory safety issues, not just use after free. For example: let mut x: Result<i32,f32> = Ok(1); let y = x.as_ref().unwrap(); x = Err(1.0); println!("{}", y); // unsafe cast of float to int This issue was first described to my knowledge by Dan Grossman in "Existential Types for Imperative Languages". The context was trying to make unions work in a safe dialect of C (Cyclone).