My guess (hope) is that Phi is just very new and alpha, and that the author was trying to say "it might eat your homework." Nevertheless, contrast that with Xi, another new, modern text editor written in Rust:

> Incredibly high performance. All editing operations should commit and paint in under 16ms. The editor should never make you wait for anything.

> Reliability. Crashing, hanging, or losing work should never happen.

https://github.com/google/xi-editor

Xi is orders of magnitudes more mature than Phi. You can't compare 76 contributors and 1128 commits vs 1 contributor and 103 commits.

Of course you can compare them. One is way more mature, use that.

I don't even think Phi is intended to be anything other than an individual/hobby project. Has the author even commented here yet?

My point is it's not like they are intending Phi to replace sublime, they're probably just doing it for fun. Even if they are more serious, they're being honest about its short comings right now.

If you thought they were trying to determine which one to use, you misread the situation.

You can also compare apples to oranges.

There’s and interesting video about Xi called Xi: An editor for the next 20 years. I remember it was a good talk and I would recommend watching it. https://youtu.be/4FbQre9VQLI

I love what Xi's trying to do, but last time I tried the OS X frontend, it was very, very slow on large files.

I think the Phi page is just including "current state of editor" as well as "aimed for state of editor" in the README.

We've done quite a bit of performance work, and there's a bit more in the pipeline, especially horizontal scrolling of very large lines. Some of the slowness at the latter is performance bugs in CoreText; we're considering more aggressively working around those. If you're still seeing slow performance, please file an issue.

alright, tried it out on a ~10K line file i have; lines can get pretty long, up to 1000 characters. xi is better than last time i checked -- it can open the file, and is snappy near the top. it slows down a lot near the bottom, which is where the longer lines are.

sublime, for comparison, is very snappy on the file.

i also tried it out on a pathological json file, which is just one line, 429984 characters long. it hung xi for a long time, and when it loaded, was very slow. again, sublime is completely snappy on the file.

probably not worth a bug since i think it's related to long-line support, which i think is already on your radar?

cool to hear. i will check out the latest, and report perf problems, if any.

(i hope my comment didn't come across as overly negative. i am very excited about xi! :-)

It's mostly a disclaimer for the time being. I'm making no guarantees that the editor will meet those claims at it's current state - but that's the end goal.

It's trying to be the former but is still the later.

I don’t know anything about this editor other than what’s in the readme, but I can make an educated guess.

It can be a minimal and fast editor in terms of text operations.

It can be a heavy and slow editor in terms of screen rendering.

There is no inherent reason why, as it matures, it couldn’t become lighter and faster overall compared to other editors, since it actually uses available modern hardware.

Tight game-loops can be a battery drain, and especially if there are local 'go-lang' things running, inevitably, alongside the SDL bridge. I'd put it in as a clever and educated 'packages may damage your battery' fair-warning, myself.