> 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.

Certainly you pay a price for lifetimes but you buy compile time race condition detection via the borrow checker's aliasing-xor-mutability enforcement. So all that is happening is the complexity of concurrency is being made explicit and therefore easier to reason about. Many applications can be architected in a way that wouldn't ever trigger a race, so for people working on that it isn't something they would need to reason about and they can call it unneeded complexity. This is the simpler vs. simplistic distinction also made in the article. If you can be simplistic, garbage collection is less cognitively demanding, but if you are designing race free algorithms with shared memory then rust will be. I do believe more developers and applications live in the former.

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.

How is Aria's linked list document relevant on this topic? Go is the kind of language where they'd call their growable array type "List" because why not. C# did that in fact, when it gained generics they named their generic growable array List<T>

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.