I have been used both GCed language and Rust a lot and I can't agree with the quoted put into the HN Headline here. Sure rust borrow checker+move semantics are

I have been used both GCed language and Rust a lot and I can't agree with the quoted put into the HN Headline here. Sure rust borrow checker+move semantics are always there and you always have to cater to it. But they _are not_ a memory management handling tool. It's more like a ownership control tool. Which is used to get some decent semi-manual memory management, but also is used to provide some very neat concurrency guarantees, and many other forms of resource management. E.g. you don't need something like python `with` or java `try-with` it's already there as part of the borrow checker/move semantics for free. So I would rephrase the quote to: "For reliable state handling, you don't pay as you go, everyone has to pay all the time." I did remove the "in rust" part because IMHO this is pretty much always the case (at least for real world non pet projects). Either your language helps with handling state to some degree, in which case you always pay some form of price for it. Or it doesn't in which case you also pay a price for it due to it now being harder and much much more prone to get messy (in my experience guaranteed to get messy in most real world projects). Through I'm never surprised if people focused on functional programming dislike rust: Because rust is _not_ a functional language, it only has many functional elements. But the moment you try write very "functional" style code in it, you can easily end up in a world of pain. Certain common functional abstractions do not scale well if combined with the rusts ownership model (they still tend to work well in simple use-cases). Partially due to limitations of the current implementation/language design. But also some aspects seem to be very hard to solve even on a conceptual level.