From the article: "The findings reveal three recurring patterns of misplaced trust in unsafe code: trusting code not to panic, trusting user-provided implementations to be correct, and trusting the underlying system."

The call to "panic" is an effect and can be checked at compile time. Haskell does this with MonadError class, marking up code that may throw.

Rust has Turing complete type system for years and still does not have effects of any kind.

To be fair, "trusting user provided implementation" is also has something to do with effects. Proper type system would require user-provided implementation to use only certain effects and nothing else.

So two of of found shortcomings are directly related to the type system and, specifically, to the choice of original Rust implementors to not to distinguish between pure and effectful computations.

Do Rust implementors highly competent? Yes, of course! They work on Turing complete type system. Will they eliminate two of three recurring patterns? I strongly doubts so. It is a design decision and these are especially hard to change. Changing it will also break all Rust source code produced to that point of time.

Is it a scandalous situation? For me, it is. The situation is so dire, actually, that "highly competent people working" has to be defended with trivially true fact that "bugs exist in complex software no matter how hard you try," instead of addressing core problem.

Actually, software that probably has no bugs does exist, starting with the seL4 microkernel. Such software is usually pretty simplistic because that goes a long way towards proving an absence of bugs.

More practically, however, Rust has proven to have more memory safety bugs than GC languages. If you want memory safety you should go GC. If you want consistent performance or tight control over memory, and pretty good memory safety, then you should go Rust.

You may have noticed the wave of "rewritten in rust" software in recent years, whose only (?) selling point was that this makes the software somehow automatically safe and if not bug free then at least significantly lower on bugs.

This finding is just yet another nail in the coffin of that myth.

gotta remember tho that ? didn’t exist in 1.0, and now we can’t break existing code

Applying the ? operator to an Option<_> doesn't work inside a function returning io::Result<_>, for example, and turning the None from an out-of-bounds vector access into some io::Result::Err usually wouldn't make sense.

I would go so far as to say that an out-of-bounds index is always a logic error (to be handled by panicking), not an input error (to be handled with Result). And if the out-of-bounds access was caused by invalid input, then logic error consists of not checking the input before indexing.

As shown in PL/I or NEWP, C could have done it both ways, checked and unchecked when really required, e.g. PREFIX(SUBSCRIPTRANGE), PREFIX(NOSUBSCRIPTRANGE).

Likewise regarding the storage for the length, if one is willing to go the way C went down a few years later, declare a pointer and make the array storage be pointer based, e.g. BASED(MY_ARRAY_PTR).

It would be entirely unsuitable for the kind of project I work on in my day job, which requires running user-provided code (trusted code, but one that may contain many bugs) in 100 different worker threads, and if one of them crashes the other 99 must keep running. Without unwinding and recovery, we'd have to completely redesign the whole application, probably to multiprocess architecture with all its downsides.

Does the system provide ready made backoff and / or bounded CAS loop primitives? Because if you have to write the entire thing in full every time I can see why it’s get skipped.