> Decent C and C++ developers shouldn't take that long to grasp the borrow-checker. Those that don't can't be trusted coding C or C++ in the first place. Becaus

> Decent C and C++ developers shouldn't take that long to grasp the borrow-checker. Those that don't can't be trusted coding C or C++ in the first place. Because they don't have a good enough mental model of memory management to deal with it manually. In fairness to C and C++ developers: while often the problem is not understanding memory management, sometimes the problem is understanding it and having a model that doesn't mesh with borrow checking, or having a problem that needs some additional work to map into something easy to write in safe code. For instance, it takes some additional knowledge in Rust to know that if you want to build a graph, you 1) should almost always use an established graph library and not write your own, and 2) if you do need to write your own graph, you either need to use Rc, have an array of nodes and use indices, or use unsafe and raw pointers and provide a nice safe well-tested wrapper. (I'm one of the developers of Rust, and I think it's important to characterize languages fairly.)