Even if it hasn't been invented as the author claims, the question of who used it in code first is a valid one, right?

In any case, do you have some helpful comments too, maybe?

- non-square-grid cities with highways, public transport, …

- realistic synthetic populations doing non-random destination selection (nobody randomly goes to a supermarket at the other end of a city, after all)

- actual traffic simulation with jams (or at least using real traffic data)

and then evaluate both the energy use and travel times. That being said, doing this kind of thing, e.g. with ActivitySim, even for one real city, is quite a bit of work.

> code maintainability and good architecture don’t have good measurements that we can apply, because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.

One way of understanding "good" here is "actionable", imho.

> Moats were excavated around castles and other fortifications as part of the defensive system as an obstacle immediately outside the walls.

Unfortunate wording?

(I'm joking. Local trains in Tokyo area are late quite often. Doesn't matter much when there's one every <5 minutes though.)

With the current implementation you can accidentally use first heapify_max and then heappop (forgetting the _max), accidentally append something through the normal list append method, change the priority of something unknowing that that breaks the invariant, or run into problems with "Tuple comparison breaks for (priority, task) pairs if the priorities are equal and the tasks do not have a default comparison order".

These headaches could have been mostly removed if these were in a class. And the option to use a custom sequence type could have surely been preserved.

One thing I could imagine would be a kind of "Firefox tab containers" but for flatpak apps. On first launch, you'll have to select what folder will be ~ for it. Folder sharing between those is manual. (And yeah, often forgotten but you can have several users on linux. Sadly, permissions and switching are pain.)

wasm has the additional benefits of allowing something like pre-compiling binaries once on a central server and thus skipping the CPU cycles for compiling all the macro crate dependencies on every crate compile. So even the people who don't care much about the security benefits have a reason. I'm kind of the "don't care about security" side because (as said elsewhere) it's trivial (https://docs.rs/ctor/latest/ctor/) for any macro to insert code that will run when compiled binaries/tests are run. You need the entire thing in a sandbox anyway, not just the macros, and that's something that can't be provided by cargo by default.

(You could have a token that hides previous tokens, but that'd be rather closer to CoT.)