Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> the fact that we always use text editing as the de-facto solution is so weird to me since that problem is both niche and extremely complex

The reason we use that is because it is complex enough to show the problems that CRDTs solve. I would argue that this painting example is too simple. The core merge loop is:

    if pixel.created_at < newPixel.created_at {
        pixel = newPixel;
    }
this is maybe good as a first step, but I don't think it is enough to even really called an "Intro". A last-write-wins register is trivial.

Simple text inserts with a simple "insert after" CRDTs is not much more complicated but involves things like generated unique IDs without communication and how to resolve conflicts with some sort of globally consistent ordering.



I think the problem is that CRDTs don't solve the text editing problem as far as I know. They can solve a constrained version of it and they have to be sorta mixed up with other algorithms and approaches. It's like a worst case scenario for distributed systems that requires tons of complex solutions.

It's something to build up to maybe, not to start with.


I agree that it's simple, but that's exactly what makes it so powerful — it's easy to understand and yet you can do a ton with it. I've been working on a vector editor as well that's also built with just registers and maps. That one is a bit long for a blog post (although I might do a high level overview of some techniques like fractional indexing). But the point I'm trying to drive at here is that you can get really far just by combining simple CRDTs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: