[gmueckl]

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.

[dralley]

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]

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.

[cortesoft]

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]

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.

[pcwalton]

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]

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]

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