[pjmlp]

You are right, but any systems programming language that comes from the Algol or ML family doesn't suffer from "every line of code is a possible memory corruption" that C and its derivatives suffer from.

Rust or any other memory safe systems programming languages don't make all type of programming errors go away, but at least they make the memory corruption ones less likely to happen.

Also most of the C tools that help reduce memory corruption, if not hardware assisted like on SPARC v9 and Skylake, are mostly limited to having all source code available.

It feels like moving from Assembly to an higher level programming language.

[sidlls]

I mostly agree. However I have this prediction: if Rust gains popularity, then in 5-10 years (or perhaps fewer!) someone will be complaining about memory issues in a Rust library that is peppered with "unsafe" blocks that don't properly respect the safe/unsafe boundary contract.

Even the core under-the-hood Rust std library is a human-vetted set of unsafe code that the compiler simply cannot prove as much about as Safe Rust. Human-vetted things are prone to error, no matter how good the humans doing the vetting are.

[burntsushi]

> Even the core under-the-hood Rust std library is a human-vetted set of unsafe code that the compiler simply cannot prove as much about as Safe Rust. Human-vetted things are prone to error, no matter how good the humans doing the vetting are.

At some point, it has to be human vetted. I don't see another way. The key advantage is the ability to build safe abstractions from unsafe components.

Will people abuse unsafe? Absolutely. Is it a lot better than the alternatives? IMO, absolutely. :-)

In my own experience, unsafe is rarely needed. I've only ever used it for ffi and lightly in very performance critical areas of code. The regex library, for example, has almost no unsafe. Its only use is to get rid of bound checks inside the DFA's inner loop.

The most (non-ffi) unsafe I've ever used is in a snappy compression library, where most of it was a means to more efficiently shuffle bytes around without paying for memcpy (using unaligned 8 byte or 16 byte loads/stores).

There is a pretty strong tendency in the Rust community to avoid unsafe. Some libraries advertise themselves as having "no unsafe code" as a selling point precisely for the dangers you've hinted at: humans make mistakes.

[pjmlp]

Which is why on those languages most compilers have the option to turn unsafe blocks usage into compiler errors.

Which is something impossible in C, where even using plain vectors, strings or doing arithmetic requires unsafe code.

It is easier to vet lets say 10% of the code than 100%.