https://rust-unofficial.github.io/too-many-lists/
I'm not saying Rust is worse than Go. It obviously isn't. But this argument that Rust's memory management isn't more cognitively demanding than Go's memory management --- that isn't true.
It's not far from true. The fights you get into with the borrow checker can be legendary, but lifetimes serve more as gentle reminders. If you get stuck, you can always just use Rc, which is pretty close to opt-in GC. But it's rare to have to resort to Rc, because ownership is just not that much of a problem. In fact, I very rarely use Box either. All heap memory allocation is done by containers, not manually by me. I guess the main friction point for lifetimes is Rust's closures and async, but if you avoid them life is pretty simple.
In return for wearing this almost not a problem, you almost don't have to think about releasing a whole pile of other things - like closing files, sockets, and locks. They are guaranteed to be released by the same mechanism.
On balance, I would not be surprised if the cognitive balance tips Rust's way once you allow for the fact that Rust's memory management also gives you robust resource management for free.
The better example actually comes from the article: returning a struct and an iterator over that struct isn't possible in rust. Heck, initializing a struct to return an iterator might lead to issues. Most people will encounter this before needing a linked list and the lesson it teaches will help out with the linked list.
An ordinary race condition would be e.g. you put the cat out of the front door, then you walk to the kitchen and close that door - well, the cat might race around the outside of the house and get in first. Our world has race conditions, Rust doesn't solve them, take appropriate care.
A data race is much stranger, it's caused by a difference between how humans think about programming ("Sequential consistency" ie time's arrow X causes Y, therefore Y happens after X) and how the machine works (a modern multi-core computer does not exhibit this consistency) maybe you and your house mate both pick up the cat and she tries to put it out the kitchen door, you try to put it out the front door, this seems to work fine mostly but then on Tuesday the cat explodes, everything is covered in cat fur, messy. Rust actually has a whole layer of extra stuff beyond the aliasing-XOR-mutability to prevent this mistake because humans struggle to reason properly about software which loses sequential consistency so it almost doesn't matter what it "means" if this is lost.
So the linked list is a thing Go doesn't have at all, in Go the equivalent document probably just reminds you of Go's rule "Don't be clever". Thanks Go, I'll keep it in mind.
Generally the argument is that non-GC languages require you to worry about memory management because of Use-after-free, but of course safe Rust just won't compile if you wrote a typical use-after-free so that's not really extra cognitive demand.
GC’ed languages have memory related challenges too. But it simply isn’t true that these are on the same order of difficulty as the difficulties that do arise in C++.
Maybe it's just me but I cannot write a huge program in rust as easily as I can in Java or Python. I have to spend more effort bending my program to fit the language and it's semantics. I get safety and speed but it feel like I'm wearing a straitjacket for those gains paying in my time and productivity.
Sometimes that tradeoff makes sense, but if I'm writing a backend webserver or some other application why would I bother with all this effort. Just doesn't make sense to me.
