interesting text... talking about mutexes for sync... that's what atomic queues are for eliminating, and selectors on these gates enable you to execute whatever task has become ready to execute when you return to idle state, this is how #golang minimises sync cost, and the benefit is enormous - indeed it's part of how efficient production lines are designed, that you avoid sync wherever possible by allowing tasks to flow from one place to another without contention by channeling them through pipes

i do most of my state sync using atomics and channels in go for the reason that it drastically reduces the response latency, and this is something that the rest of the programming world has really not grasped and why they tend to sneer at Go - the only thing it can't do as well as kernel thread/mutex model is bulk CPU bound processing

if there was one change i would want to make to the language it would be to enable a type of thread that is designed for heavy compute, an example would be vanity key generation, and another would be a custom scheduler - and this is the edge cases where Go tends to bump into problems, i've read about extremely large scale video streaming systems that they ended up having to write a kludgy workaround to minimise a sync problem because of the opportunistic and non-deterministic coroutine scheduling

all this is to say that i think that coroutines and atomic queues would be a very helpful concept to add to the toolkit for creating smooth running sovereign organisations

but ultimately there is always gonna be some things that require the whole state to sync... a bit at least anyway