Stop making me memorize the borrow checker

I think it's telling that whenever someone raises concerns about any element of Rust, no matter how constructively, they're always met with a wall of "you must not truly get the borrow checker," or "you're using Rust wrong," or "stop trying to write <C/C++/Java/etc> in Rust!", usually with zero evidence that that is in fact what is happening. There's never anything to improve on Rust, it's always user error / a skill issue. If there ever surfaces any audio of Linus Torvalds and Ken Thompson discussing the pros and cons of the borrow checker, I expect a sea of patronising anime avatars to show up, seeking to explain Rust's invention of the concept of ownership to them.

Rust is really nifty, but there are still (many) things that could be improved in Rust, and we'd all benefit from more competition in this space, including Rust! This is not a zero sum game.

Honestly, I also think many people just want a nice ML-like with a good packaging story, and just put up with the borrow checker to get friendly C-like syntax for the Option monad, sum types with exhaustive matching, etc. This is a use case that could very much benefit from a competitor with a more conventional memory model.

> whenever someone raises concerns about any element of Rust, no matter how constructively,

I don't think that it is a very constructive article. The author's critique of Rust raises questions like "how to do it better" but there are not answers.

> they're always met with a wall of "you must not truly get the borrow checker,"

Yeah, it is frustrating in this case particularly. The author openly states that he doesn't want to learn all the quirks of the borrow checker, and people respond to it with "you just don't get the borrow checker". I can see how this answer could be helpful, but if it was expanded constructively, if there was an explanation how it can become easy to deal with problems the author faces if you understood the borrow checker. OTOH I cannot see how such an argument can be constructed without a real example with the real code and the history of failed changes to it.

I personally feel, that the borrow checker is simple, if you got it. And the author's struggles just go away, if you got it. You can easily predict what will happen if you try this or that changes to the code, and you know how to do something so the borrow checker will be happy. But I cannot elaborate and to make it clear how it works.