Edit is now open source

One of the strongest example for me is newtypes. I strongly believe in Parse, don't validate (https://news.ycombinator.com/item?id=21476261) and think Rust's newtype pattern is able to really enforce this strongly.

When writing a Rust program, I can often basically express it as a single value (the input) being sequentially converted in type. The typestates, if you choose this name, allow great compile-time verification of most desired properties. You are really forced to describe the way the core logic flows in a modular way.

However this is just one and likely not even the most prominent aspect making Rust so great. Local reasoning also becomes easier via explicit opt-in mutability, and function signatures always being the only relevant source of truth when regarding their compile-time evaluatability (especially compared to C++ templates). No accessing uninitialized memory, a very simple implied notion of a constructor as merely a method without a self parameter, soundness of all received types, likely much more...

Hey all! I made this! I really hope you like it and if you don't, please open an issue: https://github.com/microsoft/edit

To respond to some of the questions or those parts I personally find interesting:

The custom TUI library is so that I can write a plugin model around a C ABI. Existing TUI frameworks that I found and were popular usually didn't map well to plain C. Others were just too large. The arena allocator exists primarily because building trees in Rust is quite annoying otherwise. It doesn't use bumpalo, because I took quite the liking to "scratch arenas" (https://nullprogram.com/blog/2023/09/27/) and it's really not that difficult to write such an allocator.

Regarding the choice of Rust, I actually wrote the prototype in C, C++, Zig, and Rust! Out of these 4 I personally liked Zig the most, followed by C, Rust, and C++ in that order. Since Zig is not internally supported at Microsoft just yet (chain of trust, etc.), I continued writing it in C, but after a while I became quite annoyed by the lack of features that I came to like about Zig. So, I ported it to Rust over a few days, as it is internally supported and really not all that bad either. The reason I didn't like Rust so much is because of the rather weak allocator support and how difficult building trees was. I also found the lack of cursors for linked lists in stable Rust rather irritating if I'm honest. But I would say that I enjoyed it overall.

We decided against nano, kilo, micro, yori, and others for various reasons. What we wanted was a small binary so we can ship it with all variants of Windows without extra justifications for the added binary size. It also needed to have decent Unicode support. It should've also been one built around VT output as opposed to Console APIs to allow for seamless integration with SSH. Lastly, first class support for Windows was obviously also quite important. I think out of the listed editors, micro was probably the one we wanted to use the most, but... it's just too large. I proposed building our own editor and while it took me roughly twice as long as I had planned, it was still only about 4 months (and a bit for prototyping last year).

As GuinansEyebrows put it, it's definitely quite a bit of "NIH" in the project, but I also spent all of my weekends on it and I think all of Christmas, simply because I had fun working on it. So, why not have fun learning something new, writing most things myself? I definitely learned tons working on this, which I can now use in other projects as well.

If you have any questions, let me know!

Is there anything in EDIT.EXE for MS-DOS that inherently hinders porting to x64?

I wish they have implemented the same color theme as well.

It's 2025 and Windows got what *nix got in the 1970s. Better late than never!

Microsoft has recently said AI writes 30% of their code. Reimplementing things isn’t as expensive as it once was.