Item — HN Reader

I'm happy to see them cite my Rope Science series. Looking back, there were some things that xi did wrong, most importantly separating the front-end from the back-end with async communication, but the data structures and text manipulation algorithms were solid.

I'm considering starting a new, similar, series called "The Book of Monoids," which covers some of the same ground but with more of a focus on parallelism (GPU) than incremental computation.

1 comments

Could you explain why you say that it was a mistake to separate the editor frontend from the backend?

So... separating front-end from back-end in and of itself is not necessarily a problem, but using async to do it adds complexity that is not worth it. Originally, I was hoping that a CRDT or similar mechanisms could be used to smooth out all such problems in a general way (including letting plugins contribute their annotations without causing jank on the main thread), but I discovered that such a collaboration layer cannot hide the underlying explosion in the potential state space.

I wrote about this in some detail: https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...

Maybe it would have been better to embed the core inside platform-specific front-end apps using a synchronous FFI. But then, you also discovered that the platform-native GUIs are overrated, at least for this application.

Addendum: One thing that excites me about Rust is the potential to cut down on the excessive use of IPC, by letting us implement reusable libraries in a safe language that imposes minimal runtime requirements, then use Rust's powerful metaprogramming features to auto-generate safe language bindings for those libraries. That's one reason I chose Rust for AccessKit. I know diplomat [1] is making some progress in this area.

[1]: https://github.com/rust-diplomat/diplomat