> But today you can just use std::sync::LazyLock which lets you say OK, the first time somebody wants this thing we'll make it, and subsequently it just exists forever.

This corresponds to a C++ feature that has been added in C++11 (and other languages have this too AFAIK); good for libraries but but this has a runtime performance cost.

Since C++20 you can use constinit, or std::construct_at to avoid static initialization woes entirely

> Intrusive lists are one of those things where technically you might need them, but so often they're just because a C or C++ programmer knew how to write one.

True about C, and also true of most userspace applications.

However, the whole point of intrusive list (and other intrusive structures) is to flip the ownership relationship - the object owns the node, instead of the node owning the object. In other words, the intrusive list is a non-owning view over its elements. More importantly, they allow the same object to be present in multiple lists at once (as long as you add enough node hooks).

For example, you can have a pool-allocated Thread object that is simultaneously part of a queue of inactive threads of priority N, and also part of a wait queue for something else.

> A retained mode GUI looks like a hierarchy to me, how do you say it isn't?

Right, I conflated it with the other examples, my bad; there it's because of shared mutable state, children elements needing to update their parents, and lack of inheritance in Rust

> A retained mode GUI looks like a hierarchy to me, how do you say it isn't?

The problem with retained mode GUIs is that, while the widget tree is, well, a a nice hierarchical tree, the widgets and the data model often need mutable references to each other, and it's these cross-references that break the tree-based ownership model of Rust.

> Things that live forever can be immutably borrowed, no problem

And mutably too, honestly, if that's what you need: https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...