text-unicode

> C has unions, but they're not tagged. You can roll your own tagged unions, of course, but that's moving beyond it being a feature of the language. This feels like a distinction without a real difference. Hand-rolled tagged unions are how lots of problems are approached in real, professional C. And I think they're the right tool here. > the actual best approach might be totally different, but at least in staying somewhat true to your code: (...) Thanks for having a stab at it. This is more or less what I ended up with in Go. As I said, I ended up needing about 50% more lines to accomplish the same thing in Go using this approach compared to the equivalent Typescript, rust and swift. If anyone is curious, here's my C implementation: https://github.com/ottypes/libot Swift: https://github.com/josephg/libot-swift Rust: https://github.com/jos

We had to handroll our own OT implementation inhouse (based on https://github.com/ottypes/text-unicode) since we had built the system for it already. I suspect we would've used or forked CodeMirror's collab package if we were starting today. Also huge fan of yjs, but the implementation is not compatible with codemirror 6, only version 5 (AFAIK)

Well said. I've had a lot of conversations with javascript engineers over the years who've argued to me that well tuned JS will be nearly as fast as the equivalent C code. I've written plenty of little toy benchmarks over the years, and in my experience they're partly right. Well written JS code in V8 can certainly run fast - sometimes around half the speed of C code. But a massive performance gap opens up when you use nontrivial data structures. Nested fields, non-uniform arrays, trees, and so on will all cripple javascript's performance when compared to C's equivalent of simple embedded nested structs. If you couple clean C data structures with allocation-free hot paths from arenas, the performance of C will easily hit 10-20x the performance of the equivalent JS code. From memory my plain text based operational transform code does ~800k

(Author here) I agree with that conclusion. I think they're really fun to implement and explore. I've been working in the area for a decade. And I've implemented over a dozen variants of OT systems by now. And despite all that I still consistently make mistakes that are only found with a fuzzer. Even thorough unit testing is never quite enough. I recommend implementing them for the fun of it. I love it. But don't put anything you write into production until you can leave a randomized test suite running overnight without errors. Example: Random op generator: https://github.com/ottypes/text-unicode/blob/master/test/gen... Which powers this fuzzer: https://github.com/ottypes/fuzzer/blob/master/lib/index.js