[ultimaweapon]

Most C/C++ users don't understand how Rust achieve memory safety because they don't know Rust enough. They always underestimate Rust memory safety. The truth is Rust can give you nearly 100% memory safety. The point of unsafe code in Rust is to isolate unsafe operations and provide a safe interface to it. As long as you wrote that unsafe code correctly the rest of your safe code will never have memory safety problems.

[pjmlp]

They also conflate unsafe keyword with Rust, when its use in systems programming languages predates C by a decade.

Here is the most recent version of NEWP manual,

https://public.support.unisys.com/framework/publicterms.aspx...

Which started as ESPOL in early 1960's,

https://en.wikipedia.org/wiki/Executive_Systems_Problem_Orie...

Binaries with unsafe code blocks are tainted, and must be white listed by admins to allow execution in first place.

This was then followed by several languages, using unsafe code blocks, pseudo packages like SYSTEM, unsafe, unchecked,..., until finally Rust came to be.

But since most C and C++ users aren't language nerds, not even reading their own ISO specification, they are unaware of the whole safety history since JOVIAL, and naturally the whole unsafe code blocks is all about Rust.

[uecker]

I understand this perfectly. The point is that 1) memory safety is a small part of the overall picture. 2) in practice people will not build perfectly safe abstractions that are then used by 100% memory-safe code, but they will create a mess.

[Georgelemental]

> In practice people will not build perfectly safe abstractions that are then used by 100% memory-safe code

Yes, in practice they quite commonly will. `unsafe` is rare, so it’s feasible to spend lots of extra efforts to validate it.

[uecker]

Is it rare? I see it a lot, especially in scenarios where speed matters, or where you need to interface with another system.

[steveklabnik]

I mean, it depends on what you mean by "rare."

Some projects will have more than others, for example, as you mention, interfacing with other systems or hardware. (Performance is not as straightforward.)

Even then, generally speaking it's usually pretty small: the sorta-kinda-RTOS we have at work for embedded systems is about 3% unsafe in the kernel, for example.

Surveying all of crates.io [1] almost a year ago found that 20% have 'unsafe' somewhere in them; this is expected to be higher on crates.io than in all Rust code, because crates.io hosts mostly libraries, which are going to use unsafe more than application code.

However, they also found that most of those usages of unsafe are for FFI, which is not able to be done in a safe way, and is overall easier to ensure the safety of than other forms of Rust's unsafe.

1: https://rustfoundation.org/media/unsafe-rust-in-the-wild-not...

[bluGill]

I've seen Rust code where everything was in unsafe because they thought it was needed (in 1% is probably was).

[unboundedjiure]

I've also seen Java code that recursively calls 1 row from database at a time, a million times per request with 5ms latency per row. It's possible to willingly abuse almost any system that a reasonable person would deem perfectly performant or safe for the purpose under default conditions.

The question should less be about whether it's possible to try to abuse the system and more what it looks like in a very reasonable everyday scenario.