Memory safety is necessary, not sufficient

I believe you said

> any nontrivial program will have unsafe somewhere, and unsafe can cause failures arbitrarily far away from the incorrect code

But the point I was trying to make is that this claim is facially true but misses the critical context: in idiomatic Rust, the unsafe keyword is not the barrier that enforces integrity of the system.

The integrity of the system is enforced by the type checker, the same way it always is. The unsafe annotation alerts the reader that there exists an invariant the compiler can't check. Idiomatic code will have a SAFETY comment above describing the invariant. It should be locally possible to reason about how the type abstraction used to encapaulate truly enforces that invariant.

This is what Rust people are talking about when we say wrap unsafe code in a safe abstraction. If we do it right, it's no longer possible for spooky action at a distance.

Now you might go and point out the fallibility of humans and all that, and you'd be right, but that's in fact what makes it so valuable to try.

    > That's exactly how C approaches UB too.

In theory yes. In practice it's been proven that's not what happens.

    > The problem is that's untenable; any nontrivial program will have unsafe somewhere, and unsafe can cause failures arbitrarily far away from the incorrect code.

Not really. Ignoring any and all non-compiler tooling, UB in code can be traced to: A) unsafe region in code where its invariants are invalidated B) if no unsafe code exists in project, then an unsoundness bug in the Rust standard lib.

Safe code needs to be safe for any possible value of arguments, fields, variables. Doing otherwise is unsoundness bug.

In C, the code you need to look is essentially ALL of your code + C std lib. In Rust, you can focus on places where safe and unsafe code mingle. And IFF (if and only iff) your code contains 0 unsafe, can you be sure there is a Rust bug.

This however assumes any code.

Idiomatic code in Rust will treat unsafe with big large friendly letters `SAFETY: this works while X and Y hold`. How do you do this is C? Since most lines are possible source of UB do you annotate every line of code? I assume not. How do you ensure something will not be mutated? How do you ensure something is thread-safe? Do you use type bounds? And if not how?

     > If Rust doesn't give you more and better support in doing that than C does, then it's not really making a difference.

Also that's the Nirvana fallacy, Rust doesn't have to be perfect and prevent EVERY undefined behavior forever. If it's improvement over the niche it's targeting (C/C++) then it's an improvement. I.e. is it harder to find UB in Rust or in C?

Like you don't go around and say, "Well seatbelts don't prevent head injuries when you hit a wall head-on. So remove seatbelts!", you add airbags to cushion the blow.

And spoiler alert: It's giving you the airbags as well. The normal thing when encountering a UB isn't to try to track it down it's to run `miri`, it found UB as soon as it ran.

Object-capability models really shine there: https://en.m.wikipedia.org/wiki/Object-capability_model

What if the only way to access the file system was to call methods on an object that was provided to main()? Then libraries would only be able to access the file system if they got a reference to that object.

I link to them in the post, as well as discuss exactly how I came across them.

>With all due respect, these “adversial compiler” expression just makes zero sense, and takes a lot away from your comment.

I was describing how it seems these complex compilers look for excuses to give you miscompilations, this "looking for gotcha's" makes the relationship appear adversarial to me.

>Guess what, the world is complex, and software has no bound for complexity.

My argument is that it really ought to. I think there is a diminishing return.

>What if the former can create 2-10x faster code than the latter (I probably even underestimate it, loop unswitching, vectorization, etc. can account for even more differences).

In code I've used with both compilers this has not been the case. Good profiling tools and manual hotspot optimization go a really long way.

>It turns out that we can build abstractions on top of abstractions, and if it’s designed well, it will scale with complexity

GCC has not scaled with complexity well enough, that's why we have people who lament its behavior.

>Would you change back to an OS that didn’t handle multithreading as it’s too complicated?

Concurrent programming makes problems easier, not harder in my experience. For what it's worth Plan 9 has excellent concurrent programming facilities.

>Or that wouldn’t use GPUs?

GPUs these days only work on systems in large part due to graces of the vendors themselves. Would nvidia or AMD be usable (enough) on Linux if there was not dedicated people from those companies working on drivers?