I think this mirrors how concurrency really is in many applications: * a lot of services simply defer their state management to some other service - a database

I think this mirrors how concurrency really is in many applications: * a lot of services simply defer their state management to some other service - a database or document store. Typically have to use their concurrency/transaction management * In apps that have state, a lot of times the only safety is required - this state only changes in one place, I can't afford a partial read, but otherwise I don't really care about concurrency. Atoms for this. * Sometimes there is an ordering or coordination to state, but a lot of time that is producer-consumer, so core.async can be a nice fit. * In a (relatively) small subset of cases, I actually have multiple writers whose behavior I need to coordinate. STM is perfect, and I prefer it to managing my own locks in those cases.