The truth is definitely some mix of both of those things. There are cases where the borrow checker can't understand some code that everyone can agree should be

The truth is definitely some mix of both of those things. There are cases where the borrow checker can't understand some code that everyone can agree should be allowed, and maybe a larger set of cases where there's some debate about what should be allowed. The 1.0 compiler was substantially worse about this, and the introduction of "nonlexical lifetimes" in 2018 was a major improvement, though there's still plenty more to do. One of the reasons that "fighting the borrow checker" is such a common experience, is that it can be hard to tell the difference between cases like "this doesn't work because you forgot a small piece of syntax" vs "this doesn't work because you need a special helper type to make it work" vs "this doesn't work because fundamentally Rust will never allow this to work". For example, sharing objects between two threads often requires the `Arc<Mutex<...>>` pattern, which is a combination of two different helpers, and beginners who've never seen that combination before are very unlikely to discover it on their own. But once you have some experience with common patterns, and you know how to avoid writing code that will fundamentally never work, compiler errors are much more likely to be helpful. A lot of people ultimately decide that "the compiler was right all along" and that their code is really better now that they've learned to satisfy the borrow checker. Personally, I think learning how to write Rust code is a helpful shortcut to learning how to write safe and correct C/C++, because the "borrow checker in your head" pushes you towards designs that work well in all three languages. But this is definitely a matter of opinion, not to mention extreme selection/survivorship bias, etc.