Earlier quoted context omitted.
Yeah, I am really surprised they managed to make it work, actually. Rust is one of those languages it takes time to master... if you write a lot of code in it while you're learning, you're likely to make all sorts of mistakes that later will need to be cleaned up... at least, looking at Rust code I wrote when I was early in the learning process, I can't even imagine any of that code going to production... so I would…
As a relative newcomer to Rust, I'm curious to hear about those early mistakes
What it doesn't tell you is that this is frequently a result of having a design that doesn't naturally fit into the kind of more restrictive paradigm that Rust wants you to write programs in. This is a natural consequence of moving from very forgiving languages where almost anything goes (e.g., garbage-collected languages). You'll try to write your software using paradigms that are familiar to you, and many of those don't fit well into the set of restrictions Rust forces upon you.
There are escape hatches that let you get around these limitations, and people become very accustomed to using them early on. This happens because the Rust compiler tells you what's wrong and that you can use one of these escape hatches to fix it. But as you continue to build, you have to use more and more of these to overcome the mismatch in your design and the kinds of designs that fit well into Rust's ownership model.
I believe it's very important to—early in your Rust career—try and understand if and when the compiler is trying to tell you about a deeper problem with your design than simply throwing surface-level ownership nits at you. I think for some people who are very used to RAII in C++ or very strict C styles, this can come somewhat easily as a lot of the patterns are common (though not enforced at compile-time as in Rust). It is much more difficult for people who are used to garbage-collected languages that tolerate program designs that are entirely unsuitable for languages without a GC.