Why Rust and Its Memory Safety Lulls Developers into a False Sense of Security

> Developers who become over-reliant on the compiler’s safety checks may inadvertently write poorly architected or buggy code, believing that the language’s safety features will catch more than they actually do.

First off: the type system of Rust is very good.

Concurrency is mostly absolutely fearless (as advertised), but Yes, there are still footguns.

There are not more footguns than in other languages though.

So while the idea that psychologically it could be that people make more mistakes of another kind, because they think that the "magic of Rust" will guard them could indeed exist, I still prefer the help I get to no help at all.

If the same developers were to write e.g. C I am 100% sure they would make more mistakes.

> Increased Cognitive Load Leading to Mistakes Elsewhere

I believe this is (among others) a very valid concern. When I dabbled in Rust to achieve what little I did, I was positively impressed by Rust's very helpful and detailed error messages that allowed me to make productive progress in a learning-by-doing fashion. The two singular items that absorbed a disproportionate amount of trial-and-error were the 43 different ways to declare a /&?[Ss]tr(ing)?/ variable for one thing and the other was, of course, the borrow checker. I tried to understand what I was doing but despite reading numerous helpful docs and blogs I resorted to doing it the cargo cult way: just keep moving around the letters and symbols until the compiler stops complaining...

the security is really not just memory safety from its lifetime & borrow checker.

it is that from language perspective, without writing unsafe, you won't have hit undefined behaviors, while provides same level performance of C++

even with unsafe code (usually needed because of performance need), there are very clear guidelines, and tooling (miri) to help check against undefined behaviors

the pain part of C++ is that i would never be confident enough to say i didn't write some undefined behaviors by mistake/accident, and requires extra tools like UBSAN in runtime to find them (C++'s miri)

however most of the time i don't need to run miri when writing rust, as they are slow for large enough project, unless i write unsafe, where it can be well scoped to be run with miri

another aspects rust put a lot efforts on is the soundness, that comes with the type system, that you know how to and when the code needs to handle errors when using someone else's code, so you never hit problems like NullException or silent racy conditions because thread safety comes with Send & Sync trait.

all these benefits just allow people to focus on the real problem, instead of wasting time on figuring out things like "oh this is undefined behavior", "oh it can return null in this case", "oh this function cannot be used in multithreading context", when the real problem to solve is something like "I need to send this trasaction to some background worker to be processed"

> Developers may spend more mental energy wrestling with the compiler to satisfy memory safety constraints, leaving them with less bandwidth to focus on the actual problem their program is meant to solve.

Then maybe Rust was the wrong language for the problem to begin with?

Or they haven't learned and understood the borrow checker yet?

I mean a similar argument can be made against any language.

"The great freedom of C may make developers spend more time debugging all the segfaults they produce..."