[aldanor]

"Express a correct program" that might end up being incorrect due to programmer's fault.

The difference is, you can use unsafe blocks/fns in Rust, in which case it becomes equivalent to C expressiveness-wise; but you can also do the opposite and forbid(unsafe_code) altogether.

[memefrog]

All programs can be incorrect. You cannot forbid unsafe code. Its use is necessary to implement basic functionality.

[aldanor]

You absolutely can forbid unsafe code (within a scope of a particular codebases) and some projects happily do it.

"The use is necessary" = absolutely not. Lots (most) of projects wouldn't ever need to dip into unsafe code. And then there's another category where authors think they do because "that's how they would do it in C++", but in reality they don't.

[memefrog]

> You absolutely can forbid unsafe code (within a scope of a particular codebases) and some projects happily do it.

No, you can't. The standard library contains 'unsafe', all over the place. Even if you discount that, large swathes of the library 'ecosystem' contain 'unsafe' and those that don't? They depend on libraries that do.

>"The use is necessary" = absolutely not.

Relying on some unsafe code that someone else has written is still using unsafe. The code in your dependencies is code that you use, that you depend on, and that affects you. It is meaningless to say you 'don't use unsafe code' if your code is just plumbing together a bunch of libraries that contain 'unsafe' code.

>And then there's another category where authors think they do because "that's how they would do it in C++", but in reality they don't.

This common sentiment from Rust developers is, just like all their other claims, totally unfounded. 'Oh you don't really need unsafe'. Then you explain why actually, yes, you do need unsafe and you're told that you're describing a 'special case'. Well guess what, every project is a special case in some respect. Every nontrivial project is going to have something that requires unsafe code, whether it's interfacing with hardware or using a system call that hasn't been wrapped or using a third party library or implementing a complex data structure or one of many many other various things that require 'unsafe'.

And even if you don't use 'unsafe' anywhere in your code and you somehow magically know that all of your dependencies are perfectly written and all the soundness bugs in the Rust compiler are fixed (at which point you might well ask: if you can assume all your Rust dependencies are perfect, why can't you assume all your C dependencies are perfect? And also, how can you be confident in any 'unsafe' code being safe if the rules for what is 'safe' to do in unsafe aren't even written down anywhere?), then what do you get? Almost nothing. 'Memory safety' is a very narrow category. As I said above, it means 'things Rust protects against'. It wasn't a term that was popularly used before Rust became known in the way Rust means it. Even to most Rust developers and contributors, right up until release it was widely assumed that it included leak freedom. And then a couple of weeks before release that was quietly dropped and memory-holed when it was shown that you could introduce memory leaks trivially. Large amounts of supposedly 'safe' unsafe code had to be rewritten and redesigned.

Rust just doesn't give you any the guarantees that Rust evangelists love to claim. Even in memory safety. In fact, almost every language out there is MORE safe than Rust, in the sense in which Rust claims to be memory-safe! The only ones that aren't are those without garbage collection.