4 ms·

The headline is about the aspiration but not the implementation. Within the contents of the paper, it talks about CRDTs to technically implement it. I'm not f

by jasode 6y ago

The headline is about the aspiration but not the implementation. Within the contents of the paper, it talks about CRDTs to technically implement it. I'm not familiar with the technical tradeoffs but I bookmarked some past HN threads mentioning CRDT did not fare as well as OT (Operational Transform): https://news.ycombinator.com/item?id=19886883 https://news.ycombinator.com/item?id=19886883 https://news.ycombinator.com/item?id=19847622 https://news.ycombinator.com/item?id=19847622

josephg 6y ago
Modern CRDTs like Automerge and Yjs should be able to perform basically just as well as an OT based systems (like my own ShareDB) now. I ran some benchmarks using Kleppmann’s approach a few months ago[1] and I think a well implemented crdt should easily be able to do millions of edits/second. The thing that’s holding us back at the moment is the lack of good high performance native implementations of these systems. But that’s being worked on. This has only really started being true in the last year or so. [1] https://josephg.com/blog/crdts-are-the-future/ https://josephg.com/blog/crdts-are-the-future/
- WhatIsDukkha 6y ago
  I assume you are following https://github.com/automerge/automerge-rs https://github.com/automerge/automerge-rs I'm hoping this matures a bit more in the next months, seems really promising.
- tmotwu 6y ago
  If javascript/non-native CRDT implementations are responsive enough compared to existing algorithms for collaborative editing like OT, what incentives or cases exist to demand high performance native implementations? To be clear, I think this is exciting stuff and your article is great. I'm just curious if there are any open research problems in this area that would make them more appealing in production.
  - josephg 6y ago
    This sort of data structure is extremely hard to well optimize in javascript because a lot of the performance comes from finicky datastructure optimizations to keep allocations down in the fast path. JS implementations will be "fine", but I think there'd be a 20+x performance uplift between yjs and a zero allocation style rust/C implementation using btrees / skip lists. So on the server I'd rather have a native implementation - which would also remove the need to bundle a JS VM in databases. And if we have that, it should be pretty easy to pack the same code into wasm for the browser. And this is all assuming a JS-native web world. I also want CRDTs for native apps like Bear. And it'd be much easier to use a rust library than link to v8.
kevinjahns 6y ago
Neither of them says that. The xi CRDT was not about shared editing. The second paper just says that CRDTs are not superior per se. But CRDTs are being used in production for text editing and they are performant if implemented correctly (even in js). The following article shows that: https://news.ycombinator.com/item?id=24176455 https://news.ycombinator.com/item?id=24176455

by jasode 6y ago

josephg 6y ago

Modern CRDTs like Automerge and Yjs should be able to perform basically just as well as an OT based systems (like my own ShareDB) now. I ran some benchmarks using Kleppmann’s approach a few months ago[1] and I think a well implemented crdt should easily be able to do millions of edits/second. The thing that’s holding us back at the moment is the lack of good high performance native implementations of these systems. But that’s being worked on. This has only really started being true in the last year or so. [1] https://josephg.com/blog/crdts-are-the-future/ https://josephg.com/blog/crdts-are-the-future/

WhatIsDukkha 6y ago
I assume you are following https://github.com/automerge/automerge-rs https://github.com/automerge/automerge-rs I'm hoping this matures a bit more in the next months, seems really promising.
tmotwu 6y ago
If javascript/non-native CRDT implementations are responsive enough compared to existing algorithms for collaborative editing like OT, what incentives or cases exist to demand high performance native implementations? To be clear, I think this is exciting stuff and your article is great. I'm just curious if there are any open research problems in this area that would make them more appealing in production.
- josephg 6y ago
  This sort of data structure is extremely hard to well optimize in javascript because a lot of the performance comes from finicky datastructure optimizations to keep allocations down in the fast path. JS implementations will be "fine", but I think there'd be a 20+x performance uplift between yjs and a zero allocation style rust/C implementation using btrees / skip lists. So on the server I'd rather have a native implementation - which would also remove the need to bundle a JS VM in databases. And if we have that, it should be pretty easy to pack the same code into wasm for the browser. And this is all assuming a JS-native web world. I also want CRDTs for native apps like Bear. And it'd be much easier to use a rust library than link to v8.

kevinjahns 6y ago

Neither of them says that. The xi CRDT was not about shared editing. The second paper just says that CRDTs are not superior per se. But CRDTs are being used in production for text editing and they are performant if implemented correctly (even in js). The following article shows that: https://news.ycombinator.com/item?id=24176455 https://news.ycombinator.com/item?id=24176455