Honestly, many of rust’s safety promises don’t help the type of low level code I write, so I’m skeptical of the “embedded rust” push. But embedded is a huge field so some people will definitely benefit from what rust makes available.

But yeah, I think for some projects rust brings you a great type system, a gross syntax, and very little additional safety. But OTOH, on those projects writing rust will be not that different than writing C. Either language will still let you forget to sanitize a length value from an external struct that is put into a DMA engine. And either language will let you create a dangerous_u32 type that needs to be sanitized before your routines write it into a peripheral. But rust’s probably would be a little more ergonomic for the programmers, a little harder to use improperly, and involve pressing every punctuation mark on your keyboard.

You still get safety, if you write normal rust code then rust will largely behave the same.

But it allows you to for example to dereference raw pointers (and by proxy, allows pointer math).

A lot of unsafe functions become available, like unguarded array access (ie, you can go out of bounds of an array) but you have to explicitly do that.

Using unsafe doesn't disable the safety features that Rust has like ownership rules or type safety, it's an acknowledgement that undefined behaviour can exist and that it's the programmers responsibility to ensure that undefined behaviour isn't introduced into safe Rust. There's no real way around this, if you want to write to arbitrary memory addresses Rust can't magically prove that you're doing so safely but if you can prove you're doing so safely then Rust will take care of the rest and make sure you're not introducing data races, use after free, buffer overflows, etc.

None of it is safety?

I would think some of it safety, like strong type checking. But, you're right in that this isn't the primary use case of Rust.

No, you only face this in the unsafe code; the rest of your code is still safe.