[flagged]
Doesn't feel that way to me.
1. Reading the error messages. I was used to error messages verbosely printing a lot of details which were mostly irrelevant and letting the programmer sort it out, and I developed a habit of skimming them. I had a better time with Rust when I realized it was giving me information that was mostly relevant, and that I should actually read them.
2. Interpreting error messages as feedback rather than failure. I was used to error messages meaning I had done something wrong, and getting them all the time was frustrating. Watching Jon Gjengset's coding videos, I was struck that he wrote code to trigger errors deliberately in order to get feedback from the compiler. I now try to work through Rust error messages the same way I would failing unit tests; I make some small changes, I knock out the errors, and then move on to the next subtask. This keeps the number of errors small and manageable, and gets me into a tight feedback loop with the compiler.
Relatedly, I encountered the idea (in a blog post I no longer remember) that the Rust compiler is more like an automated pair programming partner than other compilers. This change in mindset really helped for me; thinking of it as a friendly helper rather than a loud complainer made the work lighter. (That's why I personally don't like the 'abusive partner' metaphor, for me that mindset makes it toilsome and miserable. Also because I've had an abusive partner, and it's nothing like that, and I could do without the reminder.)
3. Setting up my IDE to show me inline type annotations and error messages. This made the feedback loop tighter, I only have to drop into a terminal for complex or unfamiliar error messages. With practice I can fix most errors using a one-line summary.
4. With practice, I've internalized Rust's semantics, and I've stopped painting myself into corners with unnecessarily cyclic data structures and such. I also read a blog article or maybe a tweet (which I've also forgotten) about giving yourself permission to use Box or clone and not sweating every copy or allocation. It pointed out that if you were writing Python, everything would be an Arc<T>, and you'd think nothing of it; in Rust the performance cost is explicit, so you agonize over it, but a lot of the time it's not a big deal to copy some data or to perform an allocation.
My first six months with Rust were very painful and I struggled to write the simplest programs. (This was in fact, the first six months of my second attempt - the first time I tried to learn it, I gave up.) Eventually I learned how to work with it, and since then, it's my absolute favorite language to work in (though presently I mostly write Typescript and SQL, because I'm writing webapps). I tried to summarize what happened along the way and what changed.
People do sick things with lifetimes and generic associated types. Sick, sick things.
If you want sugarcoating or simply rapid prototyping I'd use a dynamic or scripting language instead.