[adastra22]

I don’t know what your point is. Unsafe blocks in the stdlib isn’t a gotcha. It’s the whole point of unsafe: you provide a validated and ideally proveably correct implementation once, with a safe wrapper. It’s how everything is implemented under the hood.

It’s like double entry accounting when you only have one pen and one writing hand. The system is broken if you ever write down only half of a transaction in one ledger: you always need to record both the flow in and flow out on both ledgers. Writing either one of them is an unsafe operation. But you can only write one thing at a time. So write them in pairs in an unsafe {} block, and reuse that block safely.

[rurban]

So you are fine in calling a language "safe", when it has unsafe blocks, which the compiler skips to check? You have to that manually, and then you are back in C++ land. That's hilarious. You can call it somewhat safe, or mostly safe, but never safe.

[sfink]

Alternatively, you can have a fully safe language, and then to get certain things done you add fundamentally unsafe FFI[1]. Or you use IPC to a process written in an unsafe language. Again, you're "back in C++ land".

It seems like your complaint is that Rust is referred to as a safe language. Which is fine; it's more correct to use the phrase "in safe Rust" rather than assuming that "in Rust" fully implies "safe". That is true, but that's a crack in a sidewalk compared to the chasm of difference between Rust and C++. Why obsess over that crack?

Should we all refer to "Python without FFI or any extensions written in C or another unsafe language" instead of "Python", to avoid asserting that Python-as-it-is-used is a safe language?

[1] Assuming it's FFI to an unsafe language, and that's the main purpose of FFI.

[adastra22]

The perfectly safe platonic ideal you are implying cannot exist. Rust is a safe language because it bounds the unsafely to the minimal, clearly demarcated area where it can be reviewed and proven (outside the bounds of the type system) to hold.

That is not "back in C++ land."

[rurban]

The perfectly safe ideal does exist and is called safe. Calling unsafe safe is not even Sophism, it is mere lying

[adastra22]

Real machines and reality aren't built out of safe primitives. Safe constructs have to be built out of unsafe components. That's just how computers work.

[rurban]

Sure, that's why safe languages forbid users to use unsafe things.

"C programmers think memory management is too important to be left to the computer. Lisp programmers think memory management is too important to be left to the user." Ellis and Stroustrup, The Annotated C++ Reference Manual.

[adastra22]

You need a systems programming language to write safe systems. That's what Rust is. Maybe there's room for a higher-level 100% safe language. Rust would be a good language to write it in.

In the mean time, in the messy world of writing software today, one does frequently enough come across the need for new safety primitives. Things that are provably correct but which the type system of your language does not support. In these instances, unsafe lets you lower down into systems code to build and safely wrap these new components.