Destroying a circular list takes some thought to make sure you don't double free, same as Rust. Rust just makes those sections of code very explicit and calls your attention to it, while in C you may end up with a segfault, or worse a program that only shows odd bugs during runtime. At least Rust is telling you that you need to put some extra thought in this section.

If you don't need manual memory management, it's obviously going to be a burden. There are still use cases for manual memory management though, and that's where Rust comes in.

Use the right tool for the job.

That's exactly the point that I made in my original comment?

I don't see an issue with 'unsafe' if it's an implementation detail and well-tested. Obviously it would be better to avoid it if possible. 'unsafe' is overkill sometimes and worth it other times.

unsafe should be IMO, reserved for only those cases where strictly needed, e.g. FFI is the clearest example.

The same can be said of C and C++, at which point, why does it matter if you use Rust?

The only thing you cannot exactly prevent is "cast_dammit_cast".

All of these things have a larger cost than Rust: you're forced to use pervasive reference counting and very defensive data structures. Rust allows you to get away with pointers deep into other things, as well as aggressive data structures, all in safe code.

Rust also has reliable use-after-move defense for arbitrary resources (not just vague dynamic protections for only the memory resource), and defends against data races. That is, Rust has true safety in a way that can give higher performance than approximate safety in C++.

Static analysers and code reviews are not always possible, depending on the target OS and compiler being used, or how the whole project across teams is organized.