> But some of its fans conflate "prevents memory safety bugs" with "panacea", at least by implication, as I perceive it.

While you may be right, I have never seen this happening (and I participate a lot in online discussions about Rust); people seem to be very careful about saying that Rust prevents memory safety bugs, not bugs in general. People do say that the type system _helps_ prevent general bugs, but that's only to the extent that any similar or more powerful type system (Haskell, xML, etc) can.

> Rust helps make doing unsafe things explicit. It doesn't prevent one from doing unsafe things.

I mean, yeah. No language can (unless it avoids FFI entirely). See https://news.ycombinator.com/item?id=12877136

Rust gives you the tools to prevent yourself from doing unsafe things (and still be able to write software).

You can get a lot of stuff done in safe Rust. When you need to drop down to unsafe Rust, you can design safe abstractions around the unsafe code, and manually verify the safety of the abstraction. This has a human component, so it's not perfect, but it's pretty close :)

The unsafe feature isn't just there for explicitness, it is designed to provide the ability to do this -- the ability to design safe abstractions.

> for "low level" systems programming is going to have to make use of plenty of Rust's "unsafe" constructs.

Designing an operating system low level enough? There are a bunch of initiatives to write an OS (both serious and as a learning project) in Rust. As far as I've seen, all of them avoid unsafe code like the plague and design safe abstractions around everything so that they only need a smattering of unsafe code. os.phil-opp.com has a bunch of blog posts on OS design in Rust, some of which explicitly demonstrate this pattern (e.g. the page table one).

When you say "When one uses exclusively (or almost exclusively) the "memory safe" features of the language", you're talking about basically the entire target audience of Rust, and this includes low level users. Rust isn't supposed to be used with lots of unsafe everywhere; and folks have tried hard to make it so that this isn't necessary even for low level applications (the Zinc project, while no longer maintained, is an example of this for embedded software). Of course there are areas where you'll be using more unsafe code than others, but you're still supposed to be "almost exclusively" using safe Rust code. If you need unsafe everywhere for your low level application then that's something you should bring up with the Rust community. (To be clear, the Rust ecosystem and language right now has some issues that crop up in low level development, but these are being worked on)

In fact, there is only one place where I've seen unsafe code being sprinkled around liberally, and that's when binding to a C/++ library. Currently my job involves a lot of this, and I'm trying to make it safer (largely succeeding!), but it's still has a higher density of unsafe code than, say, Phil's Rust OS (or I think Redox, but I haven't looked at that in a while). In this case, though, you're already talking to C/++ and there's inherent unsafety there (plus an impedance mismatch), so you can't always blame Rust for it :)

------

I guess you're right that "Rust prevents memory safety issues" isn't 100% accurate because `unsafe` exists. "Rust gives you the tools to prevent memory safety issues" might be more accurate, but still misses nuance. I think for a soundbyte on Rust it's accurate enough to say (because it prevents these issues more or less as much as possible without being useless for writing software), but it's a caveat that we should probably mention more.