4 ms·

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

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.

bluGill 2y ago
I've seen Rust code where everything was in unsafe because they thought it was needed (in 1% is probably was).
- unboundedjiure 2y ago
  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.
pjmlp 2y ago
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?returnurl=%2faseries%2fdocs%2fClearPath-MCP-21.0%2f86002003-409.pdf https://public.support.unisys.com/framework/publicterms.aspx... Which started as ESPOL in early 1960's, https://en.wikipedia.org/wiki/Executive_Systems_Problem_Oriented_Language 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 2y ago
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 2y ago
  > 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 2y ago
    Is it rare? I see it a lot, especially in scenarios where speed matters, or where you need to interface with another system.
    - steveklabnik 2y ago
      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-notes-on-the-current-state-of-unsafe-rust/ https://rustfoundation.org/media/unsafe-rust-in-the-wild-not...

bluGill 2y ago

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

unboundedjiure 2y ago
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.

pjmlp 2y ago

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?returnurl=%2faseries%2fdocs%2fClearPath-MCP-21.0%2f86002003-409.pdf https://public.support.unisys.com/framework/publicterms.aspx... Which started as ESPOL in early 1960's, https://en.wikipedia.org/wiki/Executive_Systems_Problem_Oriented_Language 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 2y ago

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 2y ago
> 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 2y ago
  Is it rare? I see it a lot, especially in scenarios where speed matters, or where you need to interface with another system.
  - steveklabnik 2y ago
    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-notes-on-the-current-state-of-unsafe-rust/ https://rustfoundation.org/media/unsafe-rust-in-the-wild-not...