5 ms·

I do not get peoples' obsession with CRDTs. They are useful in a limited set of use cases when your operations are commutative but having only commutative opera

I do not get peoples' obsession with CRDTs. They are useful in a limited set of use cases when your operations are commutative but having only commutative operations is pretty rare except for some almost exotic use cases. Distributed document editing is for some reason a reoccurring theme but document editing operations are all but commutative. What people then build with all kinds of ad hoc conflict resolution strategies is barely worth being called a CRDT - nothing there is conflict-free, you are just defining conflicts away. Sometimes that works okay, at least for a limited uses case, but the resulting operations are rarely general, and sometimes they are just weird.

Existenceblinks 4y ago
About to say the same, solving application level conflict for well-defined data structure could also skip the CRDT which is sort of protocol level altogether. Plus, real-time collaboration is just for poor work process. It's very rare any app would want synchronous operations on data from different actors at the same time without work process. Even brainstorming isn't a good fit for this type of communication.
kiwicopple 4y ago
I touch on this in the blog post: I personally believe CRDTs are the future. *For some things.* It’s possible that developers will need to be selective about their “level” of offline support [example table for a blog post] Perhaps it’s not that important if the title has a “last write wins” strategy, because it’s rarely updated and less likely to have a merge conflict. But it is critical to use a smarter algorithm for the content of the blog post, especially in a team where multiple users are editing a blog post at the same time.
- danbruc 4y ago
  The C in CRDT is for conflict-free, i.e. there must not be any conflicts between operations. Incrementing and decrementing a counter, the final result will be the same independent of the order of operations. You can almost not get any further away from a CRDT than last write wins. And for more complicated merge strategies you are essentially guessing what the desired result is but you do not know and everything really depends on the quality of your guesses. Like the example with the changed fruits in the list, maybe one or the other should end up in the final result, maybe both, maybe none. The correct conflict resolution strategy is not obvious and highly dependent on the use case, that is why I said that implementations are usually not general or they are only general in the sense that you can plug in any behavior you like. Compare this with a real CRDT like a counter, there there is absolutely no doubt about the desired outcome.
  - AlexErrant 4y ago
    It's on the application developer to choose the correct CRDT for the job. Last write wins is there as a CRDT of last resort - there's a trade off between the very general but "weak" LWW and the specific but "powerful" counter. (In my own app, I plan on observing "failed" LWW writes and surfacing them to the user as notifications or something transient.) Ideally one could choose a CRDT where the semantics of an application conflict are the same as CRDT conflicts, but we don't live in an ideal world. I don't think you'll find anyone arguing that CRDTs are a silver bullet.
    - danbruc 4y ago
      Maybe my point is just that those things should not be called CRDTs. There are conflicts in the basic operations and you just decide on a case by case basis how to resolve them which makes the entire construct look superficially like a CRDT but kind of ignores the core characteristic of CRDTs, namely that the operations never conflict.
      - preseinger 4y ago
        LWWRegister does provide the deterministic guarantee that operations never conflict. The "problem" is just that the decision is basically arbitrary.
  - jclem 4y ago
    An LWW register is most certainly a CRDT, it just has limited use. I think you’re making a good point about how one must be careful applying CRDTs, but I don’t think it’s accurate to say that a suboptimal merge strategy in terms of user experience means that something does not meet the definition of a CRDT. In other words, the “conflict-free” part of the term refers to the fact that all replicas converge on the same value when all updates have been exchanged. What you’re discussing seems to have more to do with concerns around intention preservation when using CRDTs. In other words, an LWW register on a text field is still a CRDT, but in many applications it is potentially a poor choice in terms of preserving the intent of user-generated operations, but determining this is something done in a case-by-case basis. If the content is a long document which users collaborate on over time, then a register is most certainly a poor choice. If it is a short text field akin to a label, an LWW register isn’t necessarily bad, because user intent is likely to replace the entire value, rather than to perform minute edits on the value.
preseinger 4y ago
> CRDTs ... are useful in a limited set of use cases when your operations are commutative As you correctly observe, very few applications that exist today have data models with operations that satisfy the requirements of CRDTs, including e.g. commutativity. But CRDTs were never meant to be a "swappable" state layer for existing applications. The idea has always been that applications would need to change how they interact with state, to a model which does satisfy those requirements. Such models can absolutely generalize, it just takes a bit of thinking.

Existenceblinks 4y ago

About to say the same, solving application level conflict for well-defined data structure could also skip the CRDT which is sort of protocol level altogether. Plus, real-time collaboration is just for poor work process. It's very rare any app would want synchronous operations on data from different actors at the same time without work process. Even brainstorming isn't a good fit for this type of communication.

kiwicopple 4y ago

I touch on this in the blog post: I personally believe CRDTs are the future. *For some things.* It’s possible that developers will need to be selective about their “level” of offline support [example table for a blog post] Perhaps it’s not that important if the title has a “last write wins” strategy, because it’s rarely updated and less likely to have a merge conflict. But it is critical to use a smarter algorithm for the content of the blog post, especially in a team where multiple users are editing a blog post at the same time.

danbruc 4y ago
The C in CRDT is for conflict-free, i.e. there must not be any conflicts between operations. Incrementing and decrementing a counter, the final result will be the same independent of the order of operations. You can almost not get any further away from a CRDT than last write wins. And for more complicated merge strategies you are essentially guessing what the desired result is but you do not know and everything really depends on the quality of your guesses. Like the example with the changed fruits in the list, maybe one or the other should end up in the final result, maybe both, maybe none. The correct conflict resolution strategy is not obvious and highly dependent on the use case, that is why I said that implementations are usually not general or they are only general in the sense that you can plug in any behavior you like. Compare this with a real CRDT like a counter, there there is absolutely no doubt about the desired outcome.
- AlexErrant 4y ago
  It's on the application developer to choose the correct CRDT for the job. Last write wins is there as a CRDT of last resort - there's a trade off between the very general but "weak" LWW and the specific but "powerful" counter. (In my own app, I plan on observing "failed" LWW writes and surfacing them to the user as notifications or something transient.) Ideally one could choose a CRDT where the semantics of an application conflict are the same as CRDT conflicts, but we don't live in an ideal world. I don't think you'll find anyone arguing that CRDTs are a silver bullet.
  - danbruc 4y ago
    Maybe my point is just that those things should not be called CRDTs. There are conflicts in the basic operations and you just decide on a case by case basis how to resolve them which makes the entire construct look superficially like a CRDT but kind of ignores the core characteristic of CRDTs, namely that the operations never conflict.
    - preseinger 4y ago
      LWWRegister does provide the deterministic guarantee that operations never conflict. The "problem" is just that the decision is basically arbitrary.
- jclem 4y ago
  An LWW register is most certainly a CRDT, it just has limited use. I think you’re making a good point about how one must be careful applying CRDTs, but I don’t think it’s accurate to say that a suboptimal merge strategy in terms of user experience means that something does not meet the definition of a CRDT. In other words, the “conflict-free” part of the term refers to the fact that all replicas converge on the same value when all updates have been exchanged. What you’re discussing seems to have more to do with concerns around intention preservation when using CRDTs. In other words, an LWW register on a text field is still a CRDT, but in many applications it is potentially a poor choice in terms of preserving the intent of user-generated operations, but determining this is something done in a case-by-case basis. If the content is a long document which users collaborate on over time, then a register is most certainly a poor choice. If it is a short text field akin to a label, an LWW register isn’t necessarily bad, because user intent is likely to replace the entire value, rather than to perform minute edits on the value.

preseinger 4y ago

> CRDTs ... are useful in a limited set of use cases when your operations are commutative As you correctly observe, very few applications that exist today have data models with operations that satisfy the requirements of CRDTs, including e.g. commutativity. But CRDTs were never meant to be a "swappable" state layer for existing applications. The idea has always been that applications would need to change how they interact with state, to a model which does satisfy those requirements. Such models can absolutely generalize, it just takes a bit of thinking.