Blog Post: Lifetime Parameters in Rust

I am thinking borrowed immutable references are shared ownership, and mutable borrows are exclusive ownership. I don't understand the mention of Box.

Am I correct to understand that you want to use Rc / Arc where you need shared mutable references where the invariants of safe mutable coordination can't be modeled by the low-level lifetimes checker? So in order words, your Rc / Arc is unsafe (i.e. not checked by the compiler) from the standpoint of mutability invariants.

Note I updated the chart in my prior post to reflect the safety of mutability issue.

Discussion of this I think should be tied into discussing optimizing temporary objects and the points I want to make about inversion-of-control and imperative versus functional structure.

I am not totally dismissing your point, as evident by my prior remark about memory/battery limitations on mobile and afaik non-tunability of the performance priorities of the current crop of mainstream GC. But I am wanting to register another perspective, which is that the cost of hosting (hardware) is probably nearly always irrelevant compared to the things that matter to humans. I spent 100X more on advertising than I did on hosting on my last commercial success.

Lately I have come to view the programmer as the customer, not the masochist who I sacrifice at the altar to the "user". In other words, the living product is the open source, not just the executable. I hope we are headed to a world where many of the users are also programmers. The world is changing. We are leaving the Industrial Age and entering the Knowledge Age. Fixed capital investment is dying. No one can amass nearly constant marginal utility economies-of-scale of knowledge creation (links to my Rise of Knowledge essay).

The last file object implicitly finalizes the parent folder object that it points to, unless the folder object has other references to it. If you use GC then finalization time won't be deterministic, but otherwise I don't see the problem nor need to "resurrect"? For deterministic finalization if you need the resources to be freed asap, you'd need either some semantic sharing mechanism or use RC.

So these were not permanently stored, yet stored long enough to escape the generational GC?

Apparently some generational GCs are not tuned to cull the older generational garbage often, so perhaps you can overwhelm it then it doesn't have enough working physical memory so is thrashing virtual memory?

These are very short-lived objects and one would think they would be cleaned from the younger garbage on each generation. Do you have any idea why this failed? Were you holding a reference to these temporary objects too long?

Edit: could it be that the generational GC was not able to be sure that you hadn't referenced the temporary objects from the mutable objects in the older region? See the a key advantage of immutability for Haskell.