It's not even the right category of criticism. The author talks about 'mathematical purity' which is something Rust sneers at. Spend just a little while with Rust and you can see that when the language is getting in your way, the driving direction it is pushing you in is towards code that will be maintainable. Which is still not about getting shit done, and is still a valid axis to prefer Go's rapid development cycle on, but if you cannot name the distinction then it is hard to believe you have spent enough time with the language to properly observe it.
I kinda agree, it's weird to me how people make a big deal about the borrow checker as if it's an evil spirit gatekeeping your code.
And if you wanna go fast instead of writing maintainable code you surely can with stuff like unwrap(), clone(), Copy.
In a way I think most people expect to pick up Rust more easily because they have expertise in other languages and are surprised when Rust feels like learning to code again, basically turning some ingrained assumptions upside down.
It really is not the kind of language where you can glaze over the introduction chapter and churn a TODO app in the same afternoon in my opinion.
>And if you wanna go fast instead of writing maintainable code you surely can with stuff like unwrap(), clone(), Copy.
That's a good approach to learning the language, but it breaks down as soon as async comes into the picture. It's basically impossible to be fluent writing async rust without a very healthy understanding of complex types, how the borrow checker works passing things across closures, etc.
