[tdbgamer]

  It's too high-level for a lot of low-level work, and too low-level for a lot of high-level work.

This is true in the very specific cases that you gave, but I believe that is the minority of use cases, not the majority.

Even the example of writing a GC that requires tons of unsafe code, that is not a good argument for making all the code unsafe. 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. Now you can proceed writing the rest of the project in safe, simple Rust.

  People will also mention "fearless concurrency", but guaranteeing the absence of data races is not hard

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.

Also, the reasoning behind "x is easy so why do I need my language to check it for me" is questionable. The whole point is that you have a guarantee. Have you never had a compiler catch a stupid mistake before it happened and felt relieved? I doubt it. Now imagine if instead of debugging stupid data races in your parallel code you can spend that time optimizing and improving it. I fail to see how this can be viewed as negative.

Sure Rust doesn't cover 100% of use cases, but it definitely covers more than you're implying. It's low-level enough that Redox OS can be written in Rust, but high-level enough that Firefox is now outpacing other browsers and parallelizing everything with Rust.

[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.