3 ms·

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 ba

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.

phyrex 5y ago
Could you explain why you say that it was a mistake to separate the editor frontend from the backend?
- raphlinus 5y ago
  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.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...
  - mwcampbell 5y ago
    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 https://github.com/rust-diplomat/diplomat

phyrex 5y ago

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

raphlinus 5y ago
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.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...
- mwcampbell 5y ago
  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 https://github.com/rust-diplomat/diplomat