| HN Mirror

> And you said, they do fail? Can I load a several GB of data from weather or LHC?

It "fails" in the same way a car fails to fly. I set out my requirements. It meets my requirements. You're intent on arguing over how my car really should have wings and a jet engine.

> I haven't really heard of Rouge or if something else that uses it.

Gitlab is one of the most prominent examples.

> But some of the choices you mentioned (like external services doing code analysis) is some of the stuff I've seen as dead ends when making a code editor (see Lure of Modular software).

Every code editor that uses language servers makes that choice. Most modern code editors either have direct support or extensions providing client support for it, with a more coming on a regular basis. I was sceptical too, but writing my own editor very quickly demonstrated that the benefits far outweighed the downsides.

It's only hard to make this work if you make it hard on yourself. Xi made it hard on themselves by implementing their own RPC and using CRDTs instead of using "off the shelf" components and making functionality tradeoffs. That's a valid choice, but it makes their experiences with modularity relatively uninteresting when considering editors that makes entirely different choices.

To specifically address one point in the link you gave:

> I think it’s worth asking the question: is it useful to have the front-end continue after the core crashes, or the other way around? I think probably not; in the latter case it might be able to safely save the file, but you can also do that by frequently checkpointing.

E.g. to this I'd answer a resounding yes, because unlike their design 1) because of the use of Ruby and DrB, most bugs that could have taken down the server doesn't take down the server because the exceptions gets forwarded to the client. 2) every window is a client in my case, so a crashing frontend means one window goes. My - as of writing this - 16 other open editor windows do not. I can make changes to the editor itself and only affect the frontends I choose to restart. I've kept meaning to add ability for the clients to reconnect, but because of #1 it's exceptionally hard to make the server crash even if I make a severely buggy update, so it's stayed far down my priority list.

More importantly, this approach meant I did not have to build any GUI support at all to support multi-window editing. Splitting a pane is done by starting another client. It's part of a general decision to focus on minimalism.

Xi had different design goals, and Xi made tradeoffs that always sounded like a lot of bikeshedding ("hand-rolled our own xi-rpc layer" for example) to me. A lot of it was interesting, but at the same time it's pretty much the opposite of what I aimed for. Xi aimed for perfectionism where I aimed for MVPs. The Xi rope implementation alone has a higher LOC count than my entire editor... If that meets their goals, then that's fine.

My entire backend is ~500 lines. Including the buffer storage. It wouldn't be that small if it tried to cater for 2GB files, or tried to cater for concurrent editing of the same piece of data from multiple clients or cater for multiple frontends written by different people in different languages.

What my design tradeoffs got me was the ability to build an editor that was capable of being my main work tool within a few months.

My point is not that other people should use my editor. Absolutely not - I have no interest in supporting that. My point is that by building a special purpose tool and picking ready-made components where possible and making choices that focuses on modular design and optimises for simplicity over making something general, I now have an editor tailor-made for my own needs in a way that other editors I have used didn't.

> Like ok, you made a toy editor that works in your case. Ok.

The fact that it works in my case means it is not a toy editor, no matter how rude you try to be about it. It's my main work tool, and has been for several years, out of choice. I have plenty of editors installed. I switched slowly, over time, as I increasingly got the features in place that made me actually prefer to use it. That it's not a tool that suits you does not make it a toy.

This kind of attitude that something needs to be generalist to be worthwhile is something I've opposed my entire career. A whole lot of things would be a lot better if more people carefully considered whether to build yet another generalist tool or whether to build specialist tooling that does a smaller subset of things well.

I get paid a lot of money to write specialist tools that will never be available to most people, and would be of little use to most people.

> Good for you, but for me and probably 90% of people, if it can't open large file, can't automcomplete, can't reference XSD schema, can't reference, can't give good overall structure, can't refactor, can't recognize SQL in strings, can't deal with macros, source gens, debugging etc. It's not that useful.

That's fine. I didn't write my editor with the intent of 90% of people using it. I wrote it with the intent of using it myself. It has the features I prioritise, and not a single feature I don't use. That means alongside the software development I do to e.g. support the ability to read the front matter of the novels I write as a hobby and cross reference and highlight character and location names matters, while XSD doesn't matter to me one bit. Not for the last 15 years at least. If XSD had mattered to me, I'd have added support for it, as supporting it is trivial (been there, written schema validators and code generators, got the PTSD).

You seem to still struggle with the idea that not every editor need to be designed to cater for you or for the needs of everyone else. Which demonstrates that you're still struggling to deal with my original point:

That there are benefits to not aiming to build a general purpose tool if a general purpose tool isn't what you need.