
Xi-Editor Retrospective - raphlinus
https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.html
======
mwcampbell
> There is no such thing as native GUI

I understand why you were disillusioned with the performance of native GUIs.
But in other areas, such as accessibility, nativeness absolutely does help.
I'm guessing you know this; I just want to make sure other developers get this
message.

Here is a quite comprehensive list of the benefits of a native GUI for
accessibility, particularly on macOS:

[https://news.ycombinator.com/item?id=18585443](https://news.ycombinator.com/item?id=18585443)

~~~
microcolonel
The accessibility APIs can be programmed against by anyone. If there is a way
to make something like this accessible to screen readers in some useful way,
it would likely involve specific accessibility work either way.

~~~
rudedogg
Not sure about other platforms, but I like the way macOS/iOS uses the
accessibility metadata to look up UI elements for testing. So in order to
"access" a button in a test, you have to do the accessibility work.

You need it to take automated screenshots too.

~~~
mwcampbell
Implementing enough accessibility to enable automated testing is a good start,
but unless you're aware of the needs of people using screen readers and other
assistive technologies (and possibly incorporate those requirements into your
automated tests), you won't automatically get full accessibility just by
exposing the information that your tests need in order to control the UI.

------
ZeroCool2u
I've been watching/rooting for Xi from a distance for a few years now. This is
an excellent retrospective. Well written, but also very honest, especially
about those all too typical project highs and lows.

I remember looking at one of Raph's early presentations and being both
convinced by his arguments for and impressed with the design decisions made,
the same ones he outlines here. After doing some of my own comparatively
rudimentary research, coming to similar conclusions as he did. It left me very
excited to watch the project develop over time.

One thing I was wondering about is that the Xi website contains a list of
front ends similar to the list in the GitHub repo, but includes a Flutter
implementation for Fuchsia[1] that is now a dead link and missing from the
GitHub list. He mentions it briefly in this retrospective as well. Any ideas
what happened to it?

[1]: [https://xi-editor.io/frontends.html](https://xi-
editor.io/frontends.html)

~~~
raphlinus
It was maintained for a little while after I left Fuchsia (almost two years
ago now), but the pace of development on Fuchsia is such that if it's not
actively maintained, it bitrots very quickly. And there aren't really any
devices running Fuchsia that need text editing at scale.

------
rl3
> _One of those was learning about the xray project. I probably shouldn’t have
> taken this personally, ..._

I've run into that phenomenon a lot with various startup projects over the
years. It's soul crushing, and often an immediate reaction is to assume
certain projects are direct competition, rendering your project fruitless.

In retrospect, this ends up almost never being the case. In a way, you become
your own worst enemy. The correct solution is to simply ignore it and press
on, but this is certainly easier said than done—especially when morale is
already low, and without the benefit of hindsight.

> _Perhaps more important, because these projects are more ambitious than one
> person could really take on, the community started around xi-editor is
> evolving into one that can sustain GUI in Rust._

In the end, I still think that counts as a success. Perhaps it will prove to
be an even greater success than the original goal.

Thanks for all these write-ups, they're excellent. Like other commenters, I've
been watching at a distance for years now. Your work is much appreciated.

~~~
smichel17
It's not a startup and the alternatives are not competitors, but I've had a
similar experience affecting my motivation to work on Red Moon.

There's two other screen filter apps on F-Droid, and at one point I proposed
that we [work together], either merging our apps or creating shared libraries.
While the other devs initially expressed some interest, they weren't
willing/able to put in the effort and nothing came of it. This has killed my
motivation to work on Red Moon. It feels like a waste of time, duplicating
other people's efforts.

That's not intrinsic to other people working separately to solve the same
problem. If Red Moon were an educational project, or if it took a unique
approach to screen filtering (like the other project I'm part of and
[crowdfunding]), then I'd feel differently. But my main motivation was
creating a FLO screen filter app, since previously I depended on the
proprietary Twilight. And while there's a handful of valid approaches to
screen filtering, the bulk of the effort is on UX, state transitions, and
working around the kinks of Android, all of which are shared.

Note: I don't bear any hard feelings towards the other devs, _genuinely_ \--
the most frustrating bit was [lack of communication], and even that is totally
understandable; it's hard to say no to something you like the idea of, even to
yourself (eg, acknowledging you'll never get to that project near the bottom
of your list).

[work together]: [https://github.com/LibreShift/red-
moon/issues/222](https://github.com/LibreShift/red-moon/issues/222)

[lack of communication]:
[https://github.com/LibreShift/TransitionScheduler/issues/14](https://github.com/LibreShift/TransitionScheduler/issues/14)

[crowdfunding]: [https://wiki.snowdrift.coop/market-research/other-
crowdfundi...](https://wiki.snowdrift.coop/market-research/other-crowdfunding)

------
saagarjha
Aww, this is really disappointing to hear but an excellent read nonetheless. I
always had Xi in the corner of my eye as a very interesting way to make a text
editor that had a lot of good things going for it: modularity, native UI,
speed…I think if it worked out it would have been really great. It's really
sad to hear that it didn't. Thank you, Raph and the rest of the Xi
contributors, for working on it for all these years; even if it didn't upend
the text editor market I am appreciative of the effort and the lessons you've
learned along the way.

Some other side conversations I've had about this that might be interesting
and relevant:

* Native UI is not always the right choice. That might seem surprising coming from someone who pushes native UI extremely strongly in general, and I don't want to be misunderstood as recommending you choose something else for your next project (if you have to ask: don't). But in some very specific contexts, such as performant text editing/rendering, it can be problematic to use a high-level control. In fact, many of the text views I use in are _not_ using the standard platform controls but a custom view doing its own drawing: Terminal.app does its own thing (it doesn't even use NSScrollView!), Xcode has the Pegasus editor written in Swift, iTerm draws text using Metal, and Sublime Text is Skia. Platform controls are meant for 99% of apps that don't need absolute control over performance or text rendering, and sometimes you can push them quite far. But in some cases it's appropriate to abandon them. (I will note that all of the examples handle actual text _editing_ very, very well. If you don't know what the standard shortcuts for editing text are for my platform, you're not going to do it right.)

* I love that LSP exists and that it makes my "dumb" editor "smart". But having worked with it a bit, I think it might suffer from some of the same problems: it uses a client-server architecture and JSON to communicate, which means it is not all that performant and needs to keep track of asynchronous state in a coherent way. And not just the state of one document, but the states of many documents, all in different contexts and workspaces, all with their own compiler flags and completion contexts and cursor locations–it is really hard to do this correctly and quickly, although many language servers do an admirably good job. Perhaps it's just "good enough" that it's here to stay, or maybe it has enough support that it can have some of its issues wrinkled out with time.

~~~
raphlinus
Thanks for the kind words!

I agree with you that getting shortcuts (and other similar aspects) right is
more important than which code is used to implement text editing. We're very
much going to try to take that to heart as we implement more text capabilities
in Druid.

Regarding LSP. Yes, while the functionality is there, it is very difficult to
implement a really polished user experience with it. I think a lot of that is
in the design of the protocol itself; it's hard to avoid annotating the wrong
region when there are concurrent edits. It's interesting to think about how to
do better, but I fear you'd be bringing in a lot of complexity, especially if
you started doing some form of Operational Transformation. I would highly
recommend that if someone were to take this on, they study xi in detail, both
for what it got right and what was difficult.

------
mov_
On the github page [https://github.com/xi-editor/xi-
editor](https://github.com/xi-editor/xi-editor):

    
    
      JSON. The protocol for front-end / back-end communication, as well as between the back-end 
      and plug-ins, is based on simple JSON messages. I considered binary formats, but the actual 
      improvement in performance would be completely in the noise. Using JSON considerably lowers 
      friction for developing plug-ins, as it’s available out of the box for most modern languages,
      and there are plenty of the libraries available for the other ones.
    

4 years later:

    
    
      The choice of JSON was controversial from the start. It did end up being a source of friction, but for surprising reasons.
    
      For one, JSON in Swift is shockingly slow.
    

_Surprising reasons?!_

~~~
raphlinus
Yes. In this discussion and on Reddit, people still talk about binary vs
textual as the source of the problem, but I've argued (based on empirical
data) that the lexical details are not the reason for the performance
problems.

Also, Swift is marketed as a fast language (also based on LLVM), yet in my
measurements it's 20x to 50x slower than Rust for JSON processing. I found
that surprising. Would you not?

~~~
saagarjha
Swift’s slowness is kind of unfortunate, although I hear that there is work
being gone to remove a lot of the lifetime cruft that was going in behind the
scenes to make it slow. And unfortunately I think the primary motivation for
Swift’s performance is driven by its primary application, which is UI
development, so “good enough” performance usually works…

~~~
pjmlp
WWDC has a couple of talks regarding runtime improvements, and low level
coding including unsafe style coding with Swift.

------
bhl
> And it [syntax highlighting] basically doesn’t fit nicely in the CRDT model
> at all, as that requires the ability to resolve arbitrarily divergent edits
> between the different processes (imagine that one goes offline for a bit,
> types a bit, then the language server comes back online and applies
> indentation).

What's a rationale for having syntax highlighting server-side as opposed to
client-side? I'm working on side project that uses ProseMirror and CRDTs
through yjs, and the idea of having a server for syntax highlighting for
editable text never occurred to me.

> Even so, xray was a bit of a wake-up call for me. It was evidence that the
> vision I had set out for xi was not quite compelling enough that people
> would want to join forces.

I think in hindsight this was a virtue. If you look at the xray project, it
died after the Microsoft acquisition of Github: [https://github.com/atom-
archive/xray/issues/177](https://github.com/atom-archive/xray/issues/177). By
not combining projects, it allowed for redundancy.

~~~
raphlinus
So, just syntax highlighting is not compelling to move out to a server. But
part of my idea is that if you have async to hide server latency, so it's not
slowing down typing, maybe you can do a much deeper analysis than just surface
syntax. Right now you get basically instant coloring and then much slower but
more accurate feedback that's generally comparable to an incremental
recompile. I was thinking that a language server might be able to give you
quick feedback on some aspects of your program before having to do all of it.

Perhaps an even better motivation is indentation. When I use editors with
regex-based indentation (the norm), I'm regularly annoyed when it gets it
wrong. Being able to budget a few milliseconds or tends of milliseconds to do
indentation that exactly matches what rustfmt or gofmt would recommend would
be worth it, imho.

~~~
jakear
VS Code’s semantic tokens are a similar concept: an initial client side pass
using a tmGrammar, then a language-server provided set of refinements.

[https://code.visualstudio.com/api/language-
extensions/semant...](https://code.visualstudio.com/api/language-
extensions/semantic-highlight-guide)

------
blondin
had that feeling...

as a side note, i think more and more people are starting to realize that the
async paradigm is not a panacea. that paradigm or at least the way we
implement it might even mean more trouble than a synchronous counterpart.

also, other editors that i feel will be sunset or not worked on at some point
are atom and brackets.

~~~
sq_
Atom already seems to have gone somewhat towards maintenance mode since
Microsoft bought Github. Feels like there's a lot less by way of features
being released and a lot more just keeping up with ecosystem/OS changes. I
could certainly be wrong though.

~~~
andrewflnr
Atom competes pretty directly against VS Code doesn't it? It makes sense that
Microsoft would consolidate their efforts.

~~~
sq_
That's what I thought, too. Hopefully the team that was working on Atom has
gotten/will get a chance to bring some of its components/features to VS Code
if it doesn't already have them.

~~~
bhl
There was this one comment when Github Codespaces got released that that's
where ex-Atom devs got moved to:
[https://news.ycombinator.com/item?id=23093150](https://news.ycombinator.com/item?id=23093150)

------
cjohansson
Front-end / interace needs to be synchronously controlled, it doesn’t feel
right otherwise. I followed xi-editor but it never was faster than emacs on
opening really large files and editing them so it never had a use case for me

~~~
fluffything
I use emacs full time, and I open large files on xi (>300 GB). When I handle
files in the 500 MB-10 GB range on emacs, I basically need to disable
everything and use "text-mode" exclusively, and yet it still struggles if the
file is only a couple of GBs long....

------
hyperion2010
> Looking back, I see much of the promise of modular software as addressing
> goals related to project management, not technical excellence.

I couldn't find this point discussed elsewhere in the comments. I think this
is one of the most important sentences in the whole article. I know this is
essentially just another perspective on Conway's law, but I think it is
important to identify factors like this early in a project if at all possible
so that human factors around development can be factored out of engineering
decisions.

I think that this is especially critical for open projects that want to
achieve long term sustainability. Open communities don't have the resources to
maintain all the packages, even if they use the same build system and follow
the same pattern, even if most of the maintenance can be automated, some human
being still has to deal each of those systems separately because they are part
of the environment surrounding that individual part of the project.

------
dilandau
Honest and thoughtful retrospective, obviously with no hidden agenda, and
written with humility. Fantastic stuff.

------
jussij
> First, TextMate / Sublime style syntax highlighting is not really all that
> great. It is quite slow, largely because it grinds through a lot of regular
> expressions with captures, and it is also not very precise.

The tree-sitter framework provides a pretty good engine for syntax highlight:

[https://github.com/tree-sitter/tree-sitter](https://github.com/tree-
sitter/tree-sitter)

------
Firehawke
It's disappointing that things didn't work out.

I'd looked at Xi about a year ago when I was finally running out of patience
with Atom's terrible performance, but the lack of a workable Windows solution
pushed me to VSCode in the end.

------
taeric
The assertion that gpu is required for good text rendering caught me off
guard. I can't claim it is wrong, but it does feel like it should be wrong.

~~~
gnachman
I sure wish it were wrong. If macOS’s text rendering primitives could be used
asynchronously or concurrently the situation would be significantly better.
I’ve spent probably hundreds of hours trying to make it fast but I’m convinced
it’s only possible if you work at Apple (as they have done quite well with
Terminal by using lots of hacks that are unavailable to me)

~~~
llimllib
(As a person who just looked away from a nearly full-screened 4k iTerm2
running the metal renderer, thank you for your efforts)

------
amedvednikov
> When doing some performance work on xi, I found to my great disappointment
> that performance of these so-called “native” UI toolkits was often pretty
> poor, even for what you’d think of as the relatively simple task of
> displaying a screenful of text.

The same thing I experienced. Text rendering performance is terrible with
Cocoa, and even worse with Win32. Calculating text width is an order of
magnitude slower than with FreeType.

That's why for my UI framework I also went from using "native" APIs to custom
GPU rendering.

~~~
mwcampbell
If your framework has a broad audience, please make sure it accounts for the
full complexity of text rendering [1] and editing [2], particularly when it
comes to internationalization. You may find that there are good reasons for
Cocoa to be as slow as it is in the measurement phase, if not the rendering
phase. And of course, please don't forget about accessibility.

[1]: [https://gankra.github.io/blah/text-hates-
you/](https://gankra.github.io/blah/text-hates-you/)

[2]: [https://lord.io/blog/2019/text-editing-hates-you-
too/](https://lord.io/blog/2019/text-editing-hates-you-too/)

------
namelosw
This is an excellent read.

I was always wondering if CRDT would really achieve encapsulation, but this
kind of things are very hard to know without trying. Thank you for you works!

------
pokstad
Is there another modern editor like Xi that strictly separates the GUI front
end (view) from the backend (model and controller)?

~~~
noobermin
It's saying one thing that you're asking for it when the article explicitly
says he believes this was a mistake from the beginning.

~~~
pokstad
That’s fine. I don’t completely agree with his analysis. Just because he
couldn’t make it work doesn’t mean someone else can’t.

~~~
blub
Maybe someone can make it work, but it's such a terrible idea that everyone
else which doesn't use this oddball architecture will be running circles
around them.

------
chubot
Tangent/clarification: the regex slowness issue is almost certainly due to
using Perl-style exponential time regexes (which are required by Sublime
syntax definitions) rather than "regular languages".

The syntect library mentioned uses fancy-regex, which is explicitly different
than Rust's default regex crate, in that it supports regex constructs that
require exponential backtracking:

[https://github.com/fancy-regex/fancy-regex](https://github.com/fancy-
regex/fancy-regex)

 _In particular, it uses backtracking to implement "fancy" features such as
look-around and backtracking, which are not supported in purely NFA-based
implementations (exemplified by RE2, and implemented in Rust in the regex
crate)._

I think "regexes" have gotten bad name so I call them "regular languages" now.
That is, RE2, rust/regex, and libc are "regular language" engines while
Perl/Python/PCRE/Java/etc. are "regex" engines.

In my experience, lexing with regular languages can beat hand written code. In
the case of Oil vs. zsh, it's beating hand-written C code by an order of
magnitude (9-10x).

[http://www.oilshell.org/blog/2020/01/parser-
benchmarks.html](http://www.oilshell.org/blog/2020/01/parser-benchmarks.html)

[https://lobste.rs/s/77nu3d/oil_s_parser_is_160x_200x_faster_...](https://lobste.rs/s/77nu3d/oil_s_parser_is_160x_200x_faster_than_it_was)

\---

 _First, TextMate / Sublime style syntax highlighting is not really all that
great. It is quite slow, largely because it grinds through a lot of regular
expressions with captures_

pedantic: I think the issue is probably more lookahead than captures ? You can
do captures quickly in a "regular language" engine.

 _It may be surprising just how much slower regex-based highlighting is than
fast parsers. The library that xi uses, syntect, is probably the fastest open
source implementation in existence (the one in Sublime is faster but not open
source). Even so, it is approximately 2500 times slower for parsing Markdown
than pulldown-cmark._

~~~
trishume
Author of syntect here: This isn't why TextMate/Sublime/VSCode/Atom style
regex parsing is slow.

The main reason is that the parsing model is applying a whole bunch of
unanchored regexes to the unparsed remainder of the line one after another
until one matches, then starting again for the next token. This means each
token parsed can require dozens of regex matches over the same characters. I
implemented a bunch of caching schemes to cut down on this number but it still
tends to need many matches per token. It sounds like Oil's lexer probably does
about one regex run per token, with probably a somewhat faster regex engine,
and sure enough it's something like 40x faster than syntect.

Oniguruma is actually pretty fast and anyhow most of the regexes in Sublime
syntax definitions are written to not require backtracking, because Sublime
has two regex engines and only uses the fast one when no backtracking is
required. In fact fancy-regex should delegate directly to Rust's regex crate
on these regexes but is somewhat slower than Oniguruma, for reasons I haven't
yet looked into (edit: see Raph's comment, it's probably heavy use of
captures, another thing Oil's lexer doesn't need).

Also note that byte-serial table-driven lexers have a speed limit of one byte
per l1 cache round trip (~5 cycles), whereas faster lexers can take advantage
of multi-byte instructions (even SIMD) and out of order execution to go much
faster, hence why pulldown-cmark is 2500x faster than syntect rather than just
40.

[edit: I should also clarify that since unlike these other parsers, syntect
takes a grammar and can parse many languages, so how fast it is depends a lot
on the grammar, I suspect the markdown grammar in particular is slower than
usual, given that pulldown-cmark runs about 250MB/s and syntect on ES6
Javascript (a complicated but well-implemented grammar) is about 0.5MB/s, so
the Markdown grammar may be 5 times slower]

~~~
saagarjha
This is probably already implemented if it does exist, but I know with a bunch
of fixed text strings you can create a NFA/trie thing using Aho-Corasick. Does
such a thing exist for regexes (specifically: one that can match "all of them
at once"), and is it used for the fast regex engine?

~~~
raphlinus
You will probably find [https://github.com/BurntSushi/aho-
corasick/blob/master/DESIG...](https://github.com/BurntSushi/aho-
corasick/blob/master/DESIGN.md) good reading. I believe captures get in the
way of using the fastest of these NFA-style techniques, though. There's a
comment from burntsushi to this effect in:
[https://lobste.rs/s/fq8uil/aho_corasick](https://lobste.rs/s/fq8uil/aho_corasick)

ETA: Heh, I'm amused to find the latter link to be another point in what seems
to be an extended conversation between Andy Chu and the Rust text-processing
community :)

~~~
chubot
Ha yes, as far as I remember, my claim about Aho-Corasick had validity, but I
definitely learned a bunch of things from that thread.

If you scroll way down you will see a benchmark I did for the "constant
string" problem.

So you can see that re2c does scale better from 1000-6000 fixed strings than
either RE2 or rust/regex. But I uncovered a whole bunch of other problems,
like re2c segfaulting, the output being slow to compile, egrep blowing up, the
non-regular heuristics of "grep" playing a role, etc.

[https://github.com/oilshell/blog-code/blob/master/fgrep-
prob...](https://github.com/oilshell/blog-code/blob/master/fgrep-problem-
benchmarks/fixed-strings.sh#L328)

    
    
        # grep is faster than both fgrep and the "optimal" DFA in native code
        # (generated by re2c).  I think grep is benefitting from SKIPPING bytes.
    
        # All times are 'user' time, which is most of the 'real' time.
        #        re2c compile | re2c code size | re2c match time | ripgrep time | RE2
        # n= 100         7 ms          11 KiB           1,566 ms         687 ms   1,398 ms
        # n=1000        66 ms          57 KiB           2,311 ms       1,803 ms   1,874 ms
        # n=2000       120 ms          93 KiB           2,499 ms       3,591 ms   2,681 ms
        # n=3000       204 ms         125 KiB           2,574 ms       5,801 ms   3,471 ms
        # n=4000       266 ms         159 KiB           2,563 ms       8,083 ms   4,323 ms
        # n=5000       363 ms         186 KiB           2,638 ms      10,431 ms   5,294 ms
        # n=6000       366 ms         213 KiB           2,659 ms      13,182 ms   6,397 ms
        # n=47,000   2,814 ms
        #
        # NOTES:
        # - egrep blows up around 400 strings!
        # - RE2 says "DFA out of memory" at 2000 strings, because it exhausts its 8 MB
        # budget.  We simply bump it up.
        # - at 48,000 words, re2c segfaults!
        # - At 10,000 words, GCC takes 36 seconds to compile re2c's output!  It's 74K
        # lines in 1.2 MB of source.
    

I meant to blog about this but never got around to it ...

As mentioned, I think you would uncover similarly interesting things by
benchmarking Sublime-like workloads with re2c's capture algorithm. They use
some fundamentally different automata-based implementation techniques.

------
archagon
Thank you for these fantastically in-depth and introspective blog posts! It’s
a pleasure to observe how a single, experimental project can spawn a dozen
different research branches, and it’s something to aspire to in my own work.
(I have probably missed many such opportunities due to laziness and lack of
curiosity.)

~~~
raphlinus
Glad you enjoy them! I certainly plan to continue writing.

------
Myrmornis
I (naively) would have thought that the IPC / multi-process model strongly
conflicted with the extremely high performance goals (e.g. time between
keypress and painting). Can anyone explain why my instinct there is wrong?

------
fluffything
Maybe the time is just not right for Xi yet.

I wish that after druid becomes production ready you'll pick it up again.

The coolest thing about Xi is that some have attempted to make it a vim
replacement, others an emacs replacement, etc. I wish it becomes a framework
that can be used to build better text editors in general.

~~~
raphlinus
I also hope to be able to pick up text editing again, but make no promises. If
not, then I hope Druid provides a solid foundation for others to build the
dream editor I envisioned.

------
stephc_int13
Too much over-engineering here.

It is always better to start with simple, dumb and reliable code, with minimal
architecture, and then grow organically.

With experience, I tend to write the less smart code possible, I felt in love
with the power of brute-forcing everything.

~~~
magicalist
> _With experience, I tend to write the less smart code possible_

I'm always amused by the hn threads patting ourselves on the backs for in
depth technical discussions[1], when so often the top comments are basically
non-specific thought leader tweets.

For those that got this far, the article is well worth reading about a design
space with difficult tradeoffs, and there are comments actually engaging with
the content below this.

[1] today brings us multiple instances in
[https://news.ycombinator.com/item?id=23664067](https://news.ycombinator.com/item?id=23664067)

~~~
saagarjha
I found some interesting ones in this thread!

------
blub
Am I the only one on HN which thought this was a bad idea all around from the
beginning? I remember that people were very enthusiastic back then because of
the Rust hype and the author's pedigree, so critics were quickly silenced.

For me, picking Rust and the JSON-based IPC were huge red flags and this post-
mortem confirms that. But what I find odd is that many are still not willing
to accept the conclusion that using Rust for a UI-intensive app is a bad idea.
And using multiple languages in a project and splitting in back-end vs. front-
end or lib + UI is also quite popular around here, unjustifiably in my opinion
when one considers the extra complexity involved.

~~~
kllrnohj
> For me, picking Rust and the JSON-based IPC were huge red flags and this
> post-mortem confirms that. But what I find odd is that many are still not
> willing to accept the conclusion that using Rust for a UI-intensive app is a
> bad idea.

This postmortem says Rust was, and still is, a great fit for the problem
domain for which it was used.

Where do you reach the conclusion that Rust is bad for UI-intensive apps? That
claim appears to have no relation to the post-mortem as Xi didn't use Rust for
the UI in the first place? Things might have been _better_ if Rust was used
for the UI if anything, as attempting to be native instead was one of the
problem areas.

~~~
blub
How does the claim that it's a great fit reconcile with the fact that the
project which was supposed to prove the said great fit was shut down? In the
end real world is the only yardstick by which projects can be reasonably
measured.

However if we want to remain positive, we could say like Edison that this
project did not fail and is merely attempt 1 of 10000 at learning how _not_ to
build UI apps with Rust. :)

> Where do you reach the conclusion that Rust is bad for UI-intensive apps?
> I've reached that conclusion by applying logic and looking at the state of
> Rust and its capabilities as a language and the scarcity of UI apps built in
> Rust.

------
signa11
one of the design goals is

> CRDT as a mechanism for concurrent modification.

i am genuinely wondering if concurrent modification is really, truly needed ?

------
jfkebwjsbx
I didn't know about Xi, but JSON, RPC, multiprocess, microservices, Async...
are all red flags.

------
fractalb
What is the successful text-editor project in Rust now? Xray seems to have
been abandoned too.

------
nickpinkston
This is how you write Xi Thought, and if you contribute enough code you can
become the Xi Dada :-)

------
ncmncm
> _it might be able to safely save the file, but you can also do that by
> frequently checkpointing_

It is always amazing to discover niches where the conceptual and practical
power of logging has not yet penetrated.

------
akhilcacharya
I was personally really intrigued by the ambitions and design decisions in Xi,
but it somehow lacked the one thing I can’t live without in a non-terminal
editor - a tree view, at least when I first tried the OSX version.

Perhaps that changed, but you’d think that would take higher feature
precedence over something like collaborative editing right?

------
m0zg
This was solving problems nobody really has, so its fate was predictable.
Here's what I think could take off like a rocket: a VSCode-like experience
that runs completely in terminal, and therefore does not require a "remote" of
any kind. Better yet if it takes most of the same plugins, to reuse the
immense amount of work people have done there (and are not going to re-do for
some hotshot new editor).

Note how none of the above mentions "async", "ropes" or "crdt".

~~~
Arnavion
I don't want to speak too much for raphlinus here [1], but I don't think it
was ever the goal to make an editor that gets a lot of downloads like a
startup pitching a product. All the things you've listed are non-goals, or at
least lower-priority goals.

The goal was to make an editor based on sound technology principles, and that
included investigating said technology principles. It turned out some of those
principles were bad ideas, and that's that.

[1]: My involvement with xi was limited to being part of conversations he had
about rendering performance on Windows in the winapi crate's IRC channel.

~~~
raphlinus
This is a bit complicated. My main goal was to make something good. I would
have liked it to be so good that lots of people would use it, but I wasn't
optimizing for popularity, and, indeed, had I been, I would have done quite a
few things very differently.

Also, thanks for those early winapi discussions. The attitude of Rust towards
winapi is one of the early reasons I started seeing Rust as being viable for
actually building GUI.

