The simplest pure functional way would be to copy the whole database instantiating a new copy with the desired change if the condition was met. That obviously doesn't scale, which is where the performance thing comes in. A still pure way would be to use a persistent tree or hash mapped trie that allows efficient reuse of the original db. There are times a purely functional approach doesn't perform well enough, but even with large scale entity component type systems in both rust and c++, the number of times I've had to use a mutex to be performant is small. Atomic is much more common, but still not common. Persistent data structures alleviate most of the need.

The best practices I adopt for rust avoid the use of mutex whenever possible precisely because of how easy a deadlock is. It turns out it is always possible. There are entire languages the disallow any mutable state, much less shared mutable state. The question becomes how much performance are you willing to sacrifice to avoid the mutex. By starting with no shared mutable state and adding it when something is too slow, you end up with very few mutexes.

I wonder if haskell would have made more sense to you at the time with everything being immutable.

If I thought violence would fix this I would certainly advocate for it, I am not a pacifist, or anything approaching one. But all the historical examples I have looked at indicate that a domestic authoritarian takeover in a polarized society cannot be violently overthrown without the overthrowers becoming roughly as autocratic if not more so. Trump is not that popular by the standard pf authoritarian takeovers. General strikes and mass nonviolent protests worked better in these situations. Though the number of times it worked is disturbingly low.

Linux still supports BE for several targets, his point, I think, was that no one ises risc-v as BE except maybe in an academic setting. I don't think llvm or gcc will even target BE, so not sure how they were going to conpule those mods anyway