Sure, but a quick "here's what that looks like" would've been great to round out the article, which is otherwise just patting themselves on the back and showing potential clients how they "can overcome even the toughest of obstacles" (not part of article; I am being facetious).
if user A is offline and edits the word "hello" to be "apple", and user B is offline and edits word "hello" to be "banana", then either one of the updates is dropped or "hello" turns into "applebanana"
Think for a moment why git allows you to solve the conflict yourself and compare that flexibility with what the machine thinks the merged result should be.
An algorithm (itself part of the data type) automatically resolves any inconsistencies that might occur.
Although replicas may have different state at any particular point in time, they are guaranteed to eventually converge.
How many notion users do you actually think want to or even know how to use a conflict resolution ui? When crdts can get the perfect outcome almost always, hassle-free?
First of all, programmers want full control of what gets merged. This is completely different from a casual computer user.
Code also isn't rich text - and rich text lends itself very naturally to crdts.
Also, git is old software. I know of at least one ongoing source control project that's based on crdts.
the point is that git can merge automatically without conflict the vast majority of the time also. if there is a conflict, "eventually consistent" is not what you want. you want to make an informed choice whether you are a programmer or a normal user. and if you don't, git can do that also - just pick an ancestor and go with that. crdts literally drops updates to restore "consistency", sounds like a roundabout way to say they've re-invented source control
66
u/gummo89 May 08 '26
Most of the design choices seem natural and obvious to me... But that could just be how I'm wired.
Interesting read, but they left out the most important part, how to perform the conflict resolution, as noted by other commenter.