I believe this. However, my concern is that the number of people willing to make it through that learning curve is small and will limit the adoption of Rust.

I'm hoping that things like the Rust Language Server and it's integration into some of the IDE's out there will help with the initial learning curve; already the rustc error output is a million times better than when I started with it.

I definitely share your concern; for me, Rust was like putting on a glove perfectly shaped for my hand. It works and prevents every basic pattern that it took 10 years to learn and start applying to all my code thereafter. If I had Rust all those years ago, it would have saved me a ton of time... but I probably would have turned my nose up at it, b/c I wouldn't have had the experience to understand what it was saving me from.

So yes, I want the learning curve to be lower, but not at the expense of losing all of the safety it brings to developing fast and reliable software.

Have they thought about allowing code to work by warning and elevating the scope so you can quickly get the procedural work done and then attack the memory usage?

I've been thinking about a good answer to this, but I don't know what it would look like. Code looks so different when you need to be concerned about mutable vs. immutable borrows. For example you might want to iterate over a list perform an action and then delete items after doing work. This needs to be broken into two blocks, one that does the iteration and then a second block to remove any elements that no longer belong.

That's an example of just two blocks, but if it's deeper structures then ignoring this until the end could cause you to go back and restructure significant sections of code to make it abide by the mutability rules.

The process I use to stay productive, is to write small blocks of code, write a unit test for it, compile, and then move on. That way I don't build up a ton of compiler debt...