It can still crash

What I was trying to showcase is that, with the same amount of syntax/effort here, Rust gives us extra benefits that C does not.

In the slides I placed a grid of 4 combinations: (correct, incorrect) on one axis, (safe, unsafe) on the other. (I recommend opening the slides to see it).

The idea is that those are orthogonal -- all 4 combinations are possible. So, for instance, a perfectly correct C function that takes a pointer and dereferences it, will still always be considered "unsafe" in Rust terms.

In the "safe quandrants", we know the functions and their code are "safe" just by looking at them -- there is no need to look at other code or their callers. This is a "property" of the "source code" of those functions -- it is not a property of the binary, or something that requires whole-system analysis to know.

And knowing that is already valuable, since as implementors we know we will not introduce UB from within the function. And, as callers, that we will not introduce UB by just calling it.

There are caveats to that, of course (e.g. if we already had UB elsewhere, we can fabricate invalid inputs), but it is a very powerful distinction. For instance, if we copy-paste those two functions (i.e. even the incorrect one) into a safe program, even replacing an existing correct function, we shouldn't be able to introduce UB.

And this helps across time, too. In C, even if today you have a perfect C program, it is very hard to make a change that keeps it perfect, even just in terms of not triggering UB.

I hope that clarifies a bit. The "explanation" above is of course very informal and hand-wavy -- the idea in the talk was not to explain it in detail, but rather it was meant to be revealing for C developers, since it shows a "difference" that "is not there" (after all, the binaries end up being the same, no?), i.e. it tries to hint at what the concepts of "safe function" and "safe code" are about and get C programmers to think "hmm... that sounds interesting, I will look it up".