zlacker

I am working on that https://github.com/gritzko/librdx Conflictless merge and overlay branches (ie freely attachable/detachable by a click). That was the pie-in-the-sky of the CRDT community for maybe 15 years. My current approach is RDX tree CRDT effectively mapping to the AST tree of the program. Like CRDT DOM for the AST, because line based diffs are too clumsy for that.

Back in the day, JetBrains tried revision-controlling AST trees or psi-nodes in their parlance. That project was cancelled, as it became a research challenge. That was 10 years ago or so. At this point, things may work out well, time will tell.

>>gritzk+(OP)
Was it cancelled? I thought MPS works that way.

>>mike_h+9a
I meant specifically revision control. JetBrains' school of thought is very much AST-centric, yes.

>>gritzk+Ci
I think MPS stores projects as serialized ASTs and can do VCS merging.

>>mike_h+Sw
Great. But MPS is not a revision control system.

>>gritzk+DE
Ah I see. You mean they were trying to build a custom VCS that had special support for AST merging. MPS uses regular git with custom merge drivers to do AST-level merging instead of textual merging, but that's a bit different

>>gritzk+(OP)
Just a clarifying question to understand if I understand librdx correctly, it seems you've implemented a language explicitly for being easy to be used as CRDTs for syncing purposes (with specific types/structures for communicating just changes too?), rather than taking an existing language and then layering that stuff on top?

>>embedd+sE1
It depends on what you mean by a language. If JSON then yes. There are ways to implement CRDT by layering on top of JSON (see Automerge) but the result is really far from idiomatic readable JSON people expect to see.

RDX is more like CRDT JSON DOM in fact, not just JSON+. If that makes sense.