It's not like people actually do this though. I've been programming Rust for 5 years now. Since three years 'mostly Rust', now 'only Rust'. As far as I've seen `unsafe` is used very sparingly in every codebase I've had to deal with. Mostly when interacting with C, as there's no way to call C without `unsafe`.

But even then that's usually abstracted away and then a safe interface being provided.

It depends if the same pressures that lead to sprinkles of locks will lead to sprinkles of unsafe.

Maybe, but the thing about unsafe is, it isn't like fairy dust so sprinkling it on stuff doesn't help. This is a common misconception from people who haven't worked with unsafe (even if they've written some Rust)

ten_things[11] = blah; // is a buffer overflow so it either won't compile or it panics

However

unsafe { ten_things[11] = blah; } // is still a buffer overflow, same effect but also Rust warns that unsafe is useless here and should be removed

Now of course we can write a potential buffer overflow in unsafe Rust, but now we're not just sprinkling unsafe on stuff and hoping, we've got a plan, perhaps a stupid plan but it's a plan so that's an improvement.

I agree with you but just for completeness the rust equivalent is unsafe { *ten_things.get_unchecked_mut(11) = blah }

Which goes to show that usually the unsafe methods are more verbose and annoying to deal with. Devs won't reach for them just out of laziness.

I'm sure you're much more knowledgeable than me about Rust at least.

Still based on my experience reading early Redox code it was chock full of unsafe blocks, and I suspect they didn't do that out of malice but to expedite development.

So the risk might still be there.

Redox: “ A quick grep gives us some stats: the kernel has about 300 invocations of unsafe in about 16,000 lines of code overall.”

https://doc.redox-os.org/book/ch01-07-why-rust.html

This is probably not an up to date number but it gives you some idea of a random snapshot in time at least.

Well if I knew less than the last guy I'm defo beat here :)

Would be interesting to see what those figures were like 5 years ago (i.e. a year or so after its initial release). It seems like the concern here is that embedded Dev for cars isn't getting getting to maturity.

I don't see why it would. Extra locks help paper over bugs you can't figure out. Unsafe would never do that.

IME It's often harder to do it the unsafe way rather than to just do it the safe way

At the end of the day it's embedded code that's inherently unsafe, so the benefits are all in the code that belongs in the safe zone. Unsafe Rust is at best equivalent to C/C++ and at worst it's a false sense of security. Mixing safe and unsafe without a clear boundary is not something I can speak to with confidence but my gut-feeling is that it's worse than C/C++.

Even OS kernels are borderline, and it's still being figured out how exactly Rust fits, but yes we are slowly moving in that direction. Kernels have a lot of logic that qualify for the safe zone, and software engineering culture that is... let's say ahead of automotive.

> Unsafe Rust is at best equivalent to C/C++ and at worst it's a false sense of security.

This is a bit of a misconception for people who've not worked with unsafe Rust. It's not like the language and most of its features disappear. It just allows a few extra features that are unsafe, like working with pointers... Which, granted, is a lot of interaction with hardware. But you can kinda "cordon" this to a small subset of the codebase dedicated to this low level hardware IO

> embedded code that's inherently unsafe

I'm not really an expert in embedded systems, so take this with a grain of salt, but that doesn't track with my experience or with my theoretical understanding of embedded systems. First off, embedded systems are just regular systems with tighter constraints and less high-level constructs. With that understanding, if embedded code is unsafe... so is any code on any system.

Second, embedded systems have peripherals that are accessed via direct memory reads and writes. Which is only unsafe if access to those peripherals is shared in an unsafe way. Sure, the rust code that reads and writes to memory addresses will use `unsafe`, but everything above that can be written without using unsafe. Which I guess makes your statement technically correct, but imo not practically correct

I would not trust your gut feeling.

If anything Rust has a clear boundary, and that's useful for all kinds of static analysis.

And I say this as a fan of D lang. I don't really see any advantage of Rust over D except popularity.