Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Interactive Intro to CRDTs (2023)

jakelazaroff.com

Post reply on HN
Print view View original

1–10 of 36 posts

Re: An Interactive Intro to CRDTs (2023)

#2

Post by anematode »

Enjoyed the article! As someone who's worked on bits of collaborative software (and is currently helping build one at work), I'd caution people from using CRDTs in general. A central server is the right tool for the job in most cases; there are certain things that are difficult to handle with CRDTs, like permissions and acquiring locks on objects.

Edit: I had an excerpt here which I completely misread. Sorry.

Re: An Interactive Intro to CRDTs (2023)

#3

Post by gritzko »

anematode wrote: post #2

Enjoyed the article! As someone who's worked on bits of collaborative software (and is currently helping build one at work), I'd caution people from using CRDTs in general. A central server is the right tool for the job in most cases; there are certain things that are difficult to handle with CRDTs, like permissions and acquiring locks on objects. Edit: I had an excerpt here which I completely misread. Sorry.

Heh. Find how to grant permissions/ acquire lock in git. You can not. That is fundamental to distributed systems.

Downside: harder to think about it all.

Upside: a rocket may hit the datacenter.

From what I remember about Figma, it can be proclaimed CRDT. Google Docs got their sync algorithm before CRDT was even known (yep, I remember those days!).

Re: An Interactive Intro to CRDTs (2023)

#4

Post by epistasis »

anematode wrote: post #2

Enjoyed the article! As someone who's worked on bits of collaborative software (and is currently helping build one at work), I'd caution people from using CRDTs in general. A central server is the right tool for the job in most cases; there are certain things that are difficult to handle with CRDTs, like permissions and acquiring locks on objects. Edit: I had an excerpt here which I completely misread. Sorry.

Here's a 2019 Figma article on this, not sure if its representative of their current system

> OTs power most collaborative text-based apps such as Google Docs. They’re the most well-known technique but in researching them, we quickly realized they were overkill for what we wanted to achieve ...

> Figma's tech is instead inspired by something called CRDTs, which stands for conflict-free replicated data types. ... Figma isn't using true CRDTs though. CRDTs are designed for decentralized systems where there is no single central authority to decide what the final state should be

https://www.figma.com/blog/how-figmas-multiplayer-technology...

Re: An Interactive Intro to CRDTs (2023)

#5

Post by anematode »

gritzko wrote: post #3
anematode wrote: post #2

Enjoyed the article! As someone who's worked on bits of collaborative software (and is currently helping build one at work), I'd caution people from using CRDTs in general. A central server is the right tool for the job in most cases; there are certain things that are difficult to handle with CRDTs, like permissions and acquiring locks on objects. Edit: I had an excerpt here which I completely misread. Sorry.

Heh. Find how to grant permissions/ acquire lock in git. You can not. That is fundamental to distributed systems. Downside: harder to think about it all. Upside: a rocket may hit the datacenter. From what I remember about Figma, it can be proclaimed CRDT. Google Docs got their sync algorithm before CRDT was even known (yep, I remember those days!).

Of course. But typical, live collaborative software doesn't need to be (and shouldn't be) decentralized. In such software it's annoying to not be able to (even speculatively) acquire unique access to an object. I'd be very surprised if Google Docs used CRDTs now.

Re: An Interactive Intro to CRDTs (2023)

#9

Post by linkdd »

Last-Write-Win CRDTs are nice, but I wish the article talked about where CRDT really shine, which is when the state truly converge in a non-destructive way, for example:

1) Counters

While not really useful, they demonstrate this well:

  - mutations are +n and -n
  - their order do not matter
  - converging the state is a matter of applying the operations of remote peers locally
2) Append-only data structures

Useful for accounting, or replication of time-series/logs with no master/slave relationship between nodes (where writes would be accepted only on a "master" node).

  - the only mutation is "append"
  - converging the state is applying the peers operations then sorting by timestamp
EDIT: add more

3) Multi Value registers (and maps)

Similar to Last-Write-Win registers (and maps), but all writes are kept, the value becomes a set of concurrent values.

4) Many more...

Each is useful for specific use cases. And since not everybody is making collaborative tools, but many are working on distributed systems, I think it's worth it to mention this.

On another note, the article talks about state based CRDTs, where you need to share the whole state. In the examples I gave above, they are operation based CRDTs, where you need to share the operations done on the state and recompute it when needed.

For example, in the Elixir ecosystem, we have Horde ( https://hexdocs.pm/horde/readme.html ) which allows distributing a worker pool over multiple nodes, it's backed by DeltaCrdt ( https://hexdocs.pm/delta_crdt/DeltaCrdt.html ).

Delta-CRDTs are an optimization over state based CRDTs where you share state diffs instead of the whole state (described in this paper: https://arxiv.org/pdf/1603.01529 ).

Re: An Interactive Intro to CRDTs (2023)

#10

Post by tl2do »

I haven't dug into this deeply, but to me CRDTs look like a P2P data structure abstracted to the programming language variable level. The article says they shine when you don't want a central server. But most communication libraries already handle authentication and multiple peers well — and if you designate one peer as canonical (via leader election), conflict resolution is solved. I'm curious what use cases make avoiding a central server worth the paradigm shift. That said, it's a choice of approach — some may prefer the CRDT paradig
Post reply on HN