This is great stuff, will need time to read it and digest. I feel that CRDTs are something that should have been invented much earlier than 2011. Formalizing the conversation around what the base level assumptions are that are necessary to build these systems is really exciting. I have a conceptual understanding of the implications of distributing state and coordination of changes on that state, but it’s so much easier for us all to get things right when there’s best practices and understanding around these concepts. It’s kind of like how Raft made an easy to understand and include consensus library, or Yjs the same for CRDTs, or libsodium makes it easy(er) to do security correctly. It helps us develop the native units of computing for distributed systems, in the “geographically distinct edge computing sense” and not in the “a bunch of nodes with fast interconnects” sense, where offline is common and coordination has major performance implications to UIs.
I find the similarities & diffferences interesting between this and CRDTs.<p>This seems to be saying that any algorithm with a monotonic output with respect to input information "has a consistent, coordination-free distributed implementation".<p>As I understand it, for data to be monotonic requires that the data is partially orderable.<p>CRDTs require partial ordering, as well as a merge() function so as to create a lattice.<p>This seems then that CRDT's have stronger requirements - this seems to make sense, since CRDT's are about sharing data, whereas this CALM theory is only talking about making a local decision.
Another related conversation when this was discussed on The Morning Paper: <a href="https://news.ycombinator.com/item?id=19316737" rel="nofollow">https://news.ycombinator.com/item?id=19316737</a>
So basically every system wich allows you to 'delete' stuff, instead of 'forgetting' it has it (distributed state) wrong.<p>Good thing, that that's not every database ever <i>cough</i>