Big thanks and props to the team on this, very exciting! Looking forward to pitching in on the guides or other areas where some contrib help may be needed.

If you looking into OTP, you'll see there's quite a but more and to some extent it does things differently than K8 (e.g., Observer, fault tolerance, concurrency and vertical/horizontal scaling w/message passing, etc.). See: https://www.manning.com/books/the-little-elixir-and-otp-guid...

The two options you mention are the ones I see used most often (with React & Vue being 3rd/4th), but I wouldn't say any of those are "frontend equivalents".

Agreed, also just want to say thanks, this is awesome news. Much appreciated!

Out of curiosity sake, Do you mind sharing what UK company you're with?

Ascential plc

whohoo! thanks for all your hard work on this!

I'm also interested to hear what the future, if any, looks like for RethinkDB. Would also be very curious to explore what can be done regarding the IP/licensing as part of that future (agree with the concerns mentioned here).

RethinkDB as a product is not dead yet, you can contribute in it. Re-Licensing attempts are already in progress , ex founders had to deal with legal issues for it so it will be long.

Thanks to Salve for writing an incredible retrospective. One thing I'd be curious to hear is whether the RethinkDB team feels they could have create the tool and potentially the company without taking on venture capital/investors (similar to PostgresSQL, which I don't think has taken on vc).

That would have been completely impossible.

that was my understanding as well, although there has occasionally been stuff written that suggested more too.

Thanks for the thoughtful post. What do you see as the next best alternative approach to OT?

If one absolutely wants real-time collaborative editing then the only (long-term) solution I see is something like a deep learning solution that continuously semantically analyzes the merged state for semantic errors. In a particular problem domain this might be 5-10 years out. In the general case, this starts to approach the level of difficulty of AGI and hence who knows when that'll happen :)

Some practical solutions are that the document starts out in a 'real-time collaborative editing' phase. After this phase is over, the document moves to a 'review' phase where the document is reviewed for semantic errors and those errors are fixed using a 'non-real-time' approach.

The only way I see at this time to avoid silent semantic errors in the first place are non-real-time approaches.

The best practices here are optimistic locking/leasing of "semantically-connected regions" (could be defined as a paragraph, document, multi-docset, worksheet, slide etc.) along with semantically useful diffs (diffs that are meaningful for an end user) for conflicts.

You could say that this is the approach taken by version control systems like git, where the semantically-connected region is the File/Document.

Semantically useful diffs for anything other than text documents is a non-trivial problem in itself. But is still more tractable than avoiding or detecting silent semantic errors with OT.