Why Did Microsoft Build Edit in Rust for Windows?

TL;DR

Microsoft built Edit in Rust because it needed a compact terminal editor with internal language support, strong Unicode handling, VT output for SSH, and first-class Windows behavior. The lead developer prototyped it in C, C++, Zig, and Rust before choosing Rust, while keeping the editor focused on basic operations rather than syntax highlighting or installable plugins. Read on to see why existing editors fell short and what tradeoffs the team made.

Transcript

You know, I've been thinking about getting into Vim for a bit. It seems like the Neovim community is really strong and it could speed up my experience writing and editing code, but I have a couple things I wish that it did that it doesn't. I wish it was written in Rust. I wish that a big company was backing it so that we would know it would be ther... Read More

Key Insights

• Microsoft Edit is a simple terminal-based text editor designed in the visual style of MS-DOS. It focuses on basic file editing rather than competing directly with feature-rich environments, providing familiar operations such as opening, saving, undoing, redoing, copying, pasting, navigation, and word wrapping.
• Edit is written entirely in Rust after its lead developer tested prototypes in C, C++, Zig, and Rust. The developer preferred Zig most, followed by C, Rust, and C++, but selected Rust because Microsoft supported it internally and Zig did not yet meet internal chain-of-trust requirements.
• A small binary is a central requirement because Microsoft wants to bundle Edit with every variant of Windows without needing additional justification for its size. This constraint affected both the decision to create a new editor and the rejection of larger existing projects, including Micro.
• VT output is an architectural requirement that helps Edit integrate smoothly with SSH instead of depending on Windows console APIs. Microsoft also required decent Unicode support and first-class Windows behavior, creating a combination of needs that the evaluated terminal editors did not fully satisfy.
• Edit uses a custom terminal user-interface library because popular frameworks either mapped poorly to plain C or were too large for the project’s binary-size target. The team also wanted an architecture that could support a plugin model around an application binary interface, according to the lead developer’s comments.
• Rust created specific implementation difficulties involving allocator support, tree construction, and linked-list cursors in stable Rust. An arena allocator was introduced mainly because building trees in Rust was considered cumbersome, although the developer still reported enjoying Rust overall after porting the editor from C.
• The custom editor took roughly four months plus additional prototyping time, about twice the lead developer’s original estimate. The developer acknowledged some not-invented-here syndrome but described the work as enjoyable, educational, and useful for gaining knowledge that could transfer to other Microsoft projects.
• Microsoft released Edit as a fully open-source project under the MIT license, with contributions visible on GitHub. The presenter viewed this openness, along with engineers publicly explaining design decisions, as evidence of Microsoft’s positive participation in open-source development and community discussion.

Questions & Answers

Q: Why did Microsoft build Edit in Rust for Windows?

Microsoft needed a small editor that could be bundled with every Windows variant while providing Unicode handling, VT output for SSH, and first-class Windows support. After prototypes in C, C++, Zig, and Rust, the lead developer chose Rust because Microsoft supported it internally, whereas Zig did not meet its internal chain-of-trust requirements.

Q: Why did Microsoft create a new terminal text editor?

Existing editors such as Nano, Kilo, Micro, and Yori did not meet Microsoft’s complete set of requirements. Microsoft wanted a compact binary, decent Unicode support, VT-based output for SSH integration, and first-class behavior on Windows.

Q: Why did Microsoft not use Micro or another existing editor?

Micro came closest to what the team wanted, but its binary was considered too large for broad inclusion with Windows. The other evaluated editors also failed to satisfy the full combination of size, Unicode, VT output, SSH integration, and Windows requirements.

Q: What features does Microsoft Edit provide?

Edit can create, open, save, and close files. It also provides undo, redo, cut, copy, paste, page navigation, and word wrap, with shortcuts such as Control S for saving and Control O for opening files.

Q: Does Microsoft Edit support syntax highlighting or plugins?

The demonstrated version has no syntax highlighting, including for the Markdown file shown. It also lacks an installable plugin ecosystem, although the custom terminal UI architecture was intended to support a plugin model around an application binary interface.

Q: How does Microsoft Edit support SSH workflows?

Edit uses VT output instead of depending on Windows console APIs. This architectural requirement helps it integrate smoothly with SSH and was considered alongside Unicode handling and first-class Windows support.

Q: What problems did the team encounter while using Rust?

The lead developer cited allocator limitations and the difficulty of building trees in Rust. The project introduced an arena allocator largely because tree construction was cumbersome, and the developer also disliked the lack of linked-list cursors in stable Rust.

Q: Is Microsoft Edit open source, and how long did it take to build?

Microsoft Edit is available on GitHub as a fully open-source project under the MIT license. Its custom implementation took roughly four months plus earlier prototyping, about twice the lead developer’s original estimate.

Summary & Key Takeaways

• Microsoft Edit is a simple terminal editor styled after MS-DOS and designed primarily for Windows. Its basic capabilities include creating, opening, saving, and closing files, plus undo, redo, cut, copy, paste, page navigation, and word wrap. It deliberately lacks syntax highlighting and a plugin system, keeping its scope and binary size limited.

• The lead developer prototyped Edit in C, C++, Zig, and Rust before settling on Rust. Zig was the developer’s favorite, but it lacked internal Microsoft support. C was used next, then abandoned because it lacked appreciated Zig features. Rust offered internal support, although allocator limitations and tree construction created frustrations.

• Microsoft wanted an editor small enough for every Windows variant, with strong Unicode handling, VT output for SSH integration, and first-class Windows support. Existing options such as Nano, Kilo, Micro, and Yori did not satisfy the complete requirements. Micro came closest, but its binary was considered too large, encouraging a custom implementation.