Technically no (only for half of libraries) but effectively yes, if you're comparing to C and C++. The fact that there might be an `unsafe` somewhere in your dependency tree just means that instead of being there being a 0% chance of a memory bug, there's 0.0001%. Whereas a C/C++ codebase of moderate size is virtually guaranteed to have many (orders of magnitude might be off but point stands).
[1]: That's the frequency of this paranoia creeping in that I observed, not of detected memory corruption, but that too I think would be counted in an integer number of percents IME.
The point of unsafe is to point you toward the areas you need to audit. Unsafe code can't be proven memory safe by the compiler [...but the rest can be]. It's far easier to audit 10 or 100 LoC of unsafe rust than 10 or 100 thousand of C++.
And even in C++ there are subsets of the language that are supposedly memory safe. But even when writing in those subsets I'm not convinced that the abstractions I'm building on are as well validated as rust.
Rust devs (like myself) aren't illusioned into believing that my code and _everything below it_ is 100% safe.
However i can positively assure you my code is 100% safe. Well, assuming no bug in Rust-lang/compiler. My _programs_ are not guaranteed to be 100% safe unless no unsafe is used, but Rust lets you know for certain what is safe, and what is unsafe.
The point isn't absolute safety in your program. The point is absolute safety where you think there is absolute safety. To strictly know what is unsafe. And to reduce the total lines that are unsafe.
edit: I'm confused by the downvotes, what is incorrect or controversial about this?
The chance is never 0%, and nobody should be thinking that way. Memory safety bugs routinely arise in JITs (e.g. JavaScript engine CVEs). In fact, memory safety issues routinely arise in CPUs (e.g. rowhammer).
In reality, terms like "memory safety" are rarely ever exact, but they're still useful descriptions. Practically, people should be thinking about frequencies, not in black and white.
I've created a memory leak in java. Not a "I forgot to free memory in a map" memory leak but a honest to goodness "This JVM is allocating heap space and losing track of that allocation". Something that required me to install a special malloc in the VM to track down the leak. This was using standard libraries (You can do it too! Go play with the Deflater and Inflater API and you'll find it makes calls off to Zlib. If not properly handled you end up leaking heap allocations).
That was the first and only time I've ran into that issue, but I ran into that issue.
The guardrails rust gives you are essentially the same that the JVM gives you. That is, use only safe code and (barring a compiler bug) you are safe. However, bad things COULD (not will) happen if you use unsafe blocks. Just like bad things can happen in JNI blocks or places where Java makes use of C libraries for functionality.
And that is what makes rust fantastic. It's got memory safety up there with JVM safety without a garbage collector. It even has nifty keywords (unsafe) to keep developers on their toes when they need it. Just like Java's JNI or Pythons C extensions.
In fact, I'd argue that rust unsafe ends up being more safe than either JNI or C extensions primarily because it is something that can be audited very quickly across all rust code bases. Have a memory issue? It's in the unsafe block.
If for new projects what type of project that is not some kernel, browser or some low level library is Rust the best tool for the job? For most type of projects I am thinking Python,Java, C#, C++ still is better .
Right now they're one of our most egregious sources of security vulnerabilities (mostly due to a lot of hands-on bit-twiddling that results in a lot of possibilities for overflow). It's gotten bad enough that a number of system developers (browsers, OSes) have been shifting to a model where codecs are strictly sandboxed, and just get a single binary input blob, and a single output blob, and don't get any other kind of access to the system they're on - it's a scorched earth problem, but it really is that bad.
The thing about trying to write one with Rust is, if you actually 'went with the flow of the language' and didn't just immediately pop into `unsafe`, you'd be able to write a really safe codec.
-but-
The real payoff is that the performance would be surprisingly good - usually a suggestion like the one I just made would absolutely wreck performance, but one of the big things about Rust is that because it lets you describe what your intent is as a programmer in such higher-level terms (despite being a machine-level language), it gives the compiler a lot more information about the scope of your intent, which opens the floodgates to potential optimizations.
For a really easy example - Rust does all variables as "immutable by default". When you're programming in C, and something is compiling your code, there are tons of opportunities where you'd go "oh, well we already calculated this, why don't we just cache it?" But the compiler can't, because it doesn't actually know what you, the human, know - that that thing won't change. Because that knowledge is available to the compiler through Rust, the compiler actually DOES know, so tons of things can get inlined, cached, and otherwise optimized for you which you'd otherwise have to do by hand.
Usually when people do these sorts of things by hand, they'll ace a couple key optimizations (usually things that show up in profiling hotspots) and completely overlook hundreds, even thousands of other potential optimizations.
There are tons of other "high level intent" things that give the compiler more info it can use to optimize, but the "immutability by default" one is a really easy one to explain.
In Rust, if I have two u8 variables and I add them together, Rust will try to figure out if it's sure at compile time that this is an overflow and if so reject it, but otherwise I get a binary which might have an overflow in it.
But in WUFFS when you add those variables together, WUFFS wants you to justify why that can't overflow, or, tell it that you know it does overflow and you want wrapping or whatever. As a result, WUFFS gets to be very confident the resulting (awful, machine generated) C is safe and correct.
As you observed, this sort of confidence also permits a lot of performance tricks. WUFFS has some very impressive (ie better than existing Rust code) benchmark scores for the (much simpler) codecs like JPEG or PNG but I don't think there's any reason it couldn't shoot for MPEG or beyond.
WUFFS is no rival to Rust. It doesn't have IO for example. Which is fine, your codec implementation shouldn't do IO. WUFFS deals in blobs of bytes. Bytes you got over the network or from a file go in, and bytes represented a decoded image, decompressed file, or whatever come out.
You can just start building new parts in rust. Like, if you're building a new audio subsystem, you can do "just that subsystem" in rust, and expose an interface for the rest of the legacy engine code to use.
You've got MSFT, Facebook, & Google all investing heavily into Rust as a replacement for C/C++. It's still early days. Rust's sweet spot for being the best tool is anything that's currently written in C/C++. If you're writing Python, Java, or C# code, then Rust is probably not the language for you (albeit Rust is getting deployed in all these places where perf is needed because it offers the performance of C/C++ with the safety of more managed languages).
At no point will it be "replace everything in Rust" (at least not in the immediate term). It'll be more like "write this component with a thin API in Rust" or "with codebases that have a C++ runtime, work out a way for the peripheries to be written in Rust".
I'll give you an example. We used the venerable addr2line (or even llvm-symbolizer) to symbolicate addresses for an executable. We used it by spinning up a process for each address to symbolicate (which is dumb, but whatever). By writing a wrapper over Gimli-rs/addr2line-rs, we were able to improve our symbolication time 1000x & reduce our memory footprint 3x. The memory footprint improvement is because Gimli is 0-copy. 100x of that speedup is because Gimli's 0-copy is also just faster at parsing the DWARF data. The next 10x is because we only parsed the DWARF once & then used that precomputed information for all addresses. The fact that that Rust tool was correctly engineered as a library + frontend meant this was relatively easy, cheap & painless to integrate into our existing C++ codebase (using the cxx crate).
Like all things, Rust is a tool. Knowing how to find the right tool for the job & deploying it well is 99% of the job. Personally, I've found the Rust libraries I've come across for systems programming to be higher quality than the equivalent C/C++ libraries because the field is green, the userbase is extremely passionate, enthusiastic & early adopteree (i.e. more technically adept), & Rust makes certain kinds of optimizations easier than they were before (so naturally people want to play around with them). Additionally, because these are all rewrites, 90% of the time the improvement is just applying more modern state of the art knowledge to existing APIs/algorithms (e.g. doing 0-copy for symbolication is a "no-brainer" but it's hard to do safely in C++).
So all serious shops are going through this self discovery process but none have decided yet they are weighing the pros and cons daily. Unable to reach that conclusion but moving closer to Rust everyday.
That sounds like someone is hopeful they bet on the right horse.