Yes, It's hard to deny the intuitive appeal, but what's notably missing from that blog post, and seemingly any other article about it, is a consideration of the cost/downsides of universal imposition of the "exclusivity of mutable references" restriction. Rust provides the RefCell wrapper to essentially circumvent the restriction on demand, but i) that also essentially circumvents the "invariant protection" benefits of the policy, and ii) you can just as easily use an equivalent wrapper[1] in C++ to impose the same restriction. At which point the difference between Rust and C++ just kind of becomes which policy do you want to be the zero-overhead default.

I mean you could imagine a hypothetical future scenario where it is demonstrated that the optimizers are good enough to essentially eliminate the run-time cost of RefCell wrappers, and a lot of Rust programmers just start wrapping everything with RefCells by default.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#exclusive-w...

> It means throwing away common data structures like linked-lists

It does not require such; the Rust standard library even has a LinkedList (https://doc.rust-lang.org/std/collections/struct.LinkedList....).

> A C++ programmer [...] may take years to get comfortable with the borrow checker.

One of my earliest / biggest revelations when learning Rust went something like:

- Rust is stupid; I've been writing code like this in C for years, but Rust rejects it.

- ...time passes...

- Oh, I understand why Rust rejects this code now.

- OH MY GOD I'VE BEEN WRITING CODE LIKE THIS IN C FOR YEARS

A conceptual borrow checker is something that every C and C++ programmer should be running in their head for every line of code that involves references / pointers that they touch. I'm happy to let the automated algorithm provided by Rust do that for me instead.