[rbehrends]

> All the unsafe GC code would be abstracted away into a module and would be more obvious to those looking at it that they will need to be watchful for undefined behavior.

That code that could be "abstracted away" would be "virtually all the code" in my example.

> Maybe for developers that are very familiar with the race conditions of parallel code, but definitely not for most people. Even seasoned developers will make mistakes with simple multithreaded code.

I'm not talking about manually guaranteeing absence of data races. I mean absence of data races as a language feature.

> Also, the reasoning behind "x is easy so why do I need my language to check it for me" is questionable.

This is not at all what I was talking about. You completely misunderstood me.

[steveklabnik]

I think you'd be surprised, even operating systems, the canonical unsafe activity, has a relatively low percentage of unsafe code. For example, https://doc.redox-os.org/book/introduction/unsafes.html says

> A quick grep gives us some stats: the kernel has about 70 invocations of unsafe in about 4500 lines of code overall.

[rbehrends]

> I think you'd be surprised, even operating systems, the canonical unsafe activity, has a relatively low percentage of unsafe code.

My example was a GC runtime, not an OS kernel. If I have only very little unsafe code, then I could just do that in C and the rest in whatever other high-level language suits my project and not see any difference.

The bigger problem – where Rust failed to pick some low-hanging fruit, IMO – is that "unsafe" is too much like the bad parts of C. There is no medium position between "everything is defined and memory-safe" and "everything may explode at a moment's notice".

My most practical need for a low-level language is a language that is in that in-between position: semantics that remain easy to comprehend and predictable even if there are no static guarantees, and where I have to use a different strategy for software assurance. The point here is that for such a language I can resort to alternate validation tools (think Ada and SPARK for an example). Rust's unsafe mode does not handle that situation well because (like C) it does not provide a foundation for alternate validation strategies.

It's perhaps also worth pointing out that I have a formal methods background. In short, I've done formal specifications/proofs for software before. In this context, safe Rust has a fairly high cost for only providing memory safety (and few other guarantees), and unsafe Rust is not a good foundation (or at least, not much better than C) for bringing advanced tools to bear.

[jononor]

There are several things that make unsafe Rust better than C wrt to ensuring correctness. For example the stronger, more expressive type-system and fewer instances of undefined behavior for common operations. The standardized, modern tools for unit-testing and fuzzing are also nicer in Rust.