GC is unacceptable for some applications. Generally speaking, shifting the memory safety checks to compile time results in better runtime performance. Is the added complexity worth the performance gain? That’s for you to decide.
This is not even close to being true, the borrow checker does not accept all memory safe programs. It tries to do a good job of accepting programs that are both safe and have simple and elegant guarantees of safety across module boundaries (which is good for extensibility and evolvability).
But there are designs that can only be expressed in Rust by using constructs that replace some of these compile-time guarantees with runtime constraints.
Second, this can be tough because it is hard to self-evaluate. The two languages have different semantics. Some stuff is UB in Rust, but well defined in C and C++, and some things that are UB in C and C++ are well defined in Rust.
What this means is, while you are correct that Rust will reject some memory safe programs, I’ve also seen so many people over the years ask questions like “why does the borrow checker disallow this?!? It’s this easy in C++!” yet they’re running afoul of semantic differences, or they forgot some property (like thread safety) that isn’t enforced by the compiler in those languages, but rustc catches it.
Tl;dr you’re technically right but in the real world it plays out more subtly than I think you’re giving it credit for.
> Failing to address these issues creates safety concerns, as users will resort to calling code that expects Rust semantics and create UB by doing so.
Absolutely. What I'm saying is that sometimes this is expressed by users as "I can do this" when they actually can't, which makes it hard to talk about how much the borrow checker truly gets in your way. They're just two different languages with two different sets of semantics, you cannot assume that everything that works well in one works well in the other, in both directions.