> but didn't make the effort because of all the stories about how hard it was to deal with the borrow checker. Then I realized that for a programmer like me tha

> but didn't make the effort because of all the stories about how hard it was to deal with the borrow checker. Then I realized that for a programmer like me that was used to managing memory in my head, the borrow checker would be a piece of cake. Yeah as you've alluded to Rust _feels_ harder, but is easier if one considers the entire effort curve of a project. Rust front loads the problem solving so the hard work is at the beginning of the project instead of C/C++ with its long tail of debugging that takes up 90% of one's effort. Of course, if you don't know that the hard work at the beginning is going to pay off it's hard to commit to it. And coders don't know that until they've tried it. It's why I think Go is a good stepping stone to Rust. Go is easier to get into and useful in its own right, but most importantly it introduces the concept of "if it compiles, it runs" to coders who are used to compilers that fight against them (ala C/C++, Java, Python, JavaScript, etc). Once someone has a taste for helpful compilers I think it's easier for them to swallow Rust. In particular that idea that the borrow checker is there to _help_ you and the supposed "difficulty" of working with it is more about the compiler being transparent with you, instead of the C/C++ way of looking at your broken program and just shrugging and going "Okay, if you say so...".