They find it immensely useful in practice only when the safe subset is useful. In C, you could say that the same definition of memory-safety exists, only the safe subset is empty, and in that case people don't find the fact that C could be described as memory-safe in that way useful at all.

And that's exactly my point. The safe subset of Rust doesn't sufficiently cover the very things that I choose a low-level language for in the first place, and the parts it does cover I can do at least as well in even safer high-level languages.

Now, I'm not saying there aren't programs where Rust's precise mix of safety and unsafety is better than the alternatives. For example, I've never written a browser rendering engine, and it's possible that I would find Rust to be the best fit for that task. I don't know that I would, but I also have no experience with that domain to suggest that I wouldn't.

You don't find it useful that use after free, double free, uninitialized memory, and many kinds of race conditions are just impossible in code that compiles?

What exactly is the low level subset you feel like you can't use?

> You don't find it useful that use after free, double free, uninitialized memory, and many kinds of race conditions are just impossible in code that compiles?

Sure, but memory safety by itself is not the reason to pick Rust because other languages do memory safety even better.

> What exactly is the low level subset you feel like you can't use?

The things that make me want to use a low-level language in the first place, such as controlling exactly when memory is allocated and freed and where exactly objects are placed in memory.

When I don't need to do these things and all I want is memory safety and performance, then I already have better options.