Zed

Zed is a text editor written in Rust by Nathan Sobo, who previously created Atom, the Electron-based editor that GitHub built, that Microsoft acquired, that Microsoft killed in favour of VS Code, and that Sobo watched die before building the exact opposite thing.

Zed is fast. Not “fast for an editor.” Fast. It opens in milliseconds. It renders at native speed. It does not contain a web browser. It does not run JavaScript. It does not allocate a gigabyte of RAM to display text. It is a native application that edits text at the speed the hardware allows, which turns out to be very fast when you remove the web browser from between the human and the text.

“Zed is what happens when someone who built an Electron editor lives with the consequences, processes the grief, and builds the opposite.”
— A Passing AI, on the arc of Nathan Sobo’s career

The Speed

Zed opens in under 200 milliseconds. VS Code opens in 2-4 seconds. This sounds like a small difference. It is not.

The 200-millisecond threshold is the boundary of perceived instantaneity — the point below which the human brain does not register a delay. Below 200 milliseconds, the tool feels like an extension of thought. Above it, the tool feels like a separate entity that must be waited for. VS Code is above the threshold. Zed is below it.

This means that opening Zed feels like opening a file. Opening VS Code feels like launching an application. The distinction is psychological but the effect is real: the developer who opens Zed opens it more often, opens it for smaller tasks, opens it for a quick edit that would not have justified waiting for VS Code to start. The tool that is fast enough to be thoughtless is the tool that gets used.

Memory usage follows the same pattern. Zed uses 80-150 MB. VS Code uses 800-1500 MB. The ratio is approximately 10:1. The Zed user can have three projects open and still use less memory than one VS Code window. The Zed user’s laptop fan is silent. The Zed user has forgotten that editors can make laptop fans spin.

“I had forgotten what a fast editor felt like. Not intellectually — I knew vi was fast. But I had forgotten the physical feeling of pressing Cmd-P and having the file appear before my finger leaves the key. Zed brought that back.”
— riclib, who has both Zed and Zed Preview installed

The Rust Advantage

Zed is written in Rust. This matters for three reasons:

1. Speed — Rust compiles to native code with no garbage collector, no runtime, no virtual machine. The performance ceiling is the hardware, not the framework.
2. Memory — Rust’s ownership model means predictable, minimal memory allocation. No GC pauses. No heap sprawl. The editor uses what it needs and nothing more.
3. Reliability — Rust’s type system catches classes of bugs at compile time that other languages catch at runtime (or, in the case of Electron applications, catch when the user notices and files a GitHub issue).

The Rust advantage is not about Rust being trendy. The Rust advantage is about Rust producing programs that behave like programs should have always behaved: fast, small, reliable. That this feels remarkable says more about what we’ve accepted from Electron than about what Rust achieves.

The Extension Gap

Zed’s weakness is its extension ecosystem. VS Code has 40,000 extensions. Zed has hundreds. The gap is significant, and the gap is the thing that keeps VS Code on many developers’ machines alongside Zed.

The extensions that matter most — language support, Git integration, AI chat — Zed has natively. The extensions that matter less but are still missed — specific framework integrations, niche language support, the particular workflow automation that one developer built and shared and a thousand developers now depend on — these take time.

The question is not whether Zed is better. Zed is better. The question is whether Zed can build the ecosystem before the developers who want to switch run out of patience and return to VS Code, where the extension they need already exists, even if it runs at Electron speed.

The Backlinks Dream

riclib has both Zed and Zed Preview installed. This is the specific behaviour of someone who is not merely using a tool but betting on it.

The bet has a condition: backlinks.

riclib’s notes live in ~/Notes/. They are markdown files with wiki-links — **brackets** connecting notes to notes, building a knowledge graph that tools like Obsidian and NotePlan visualize and navigate. The backlinks — the ability to see which notes link to the current note, not just which notes the current note links from — are the feature that makes the graph navigable, that makes the knowledge base a web instead of a list.

VS Code does not do backlinks well. Obsidian does. NotePlan does. If Zed’s extension system becomes powerful enough to understand wiki-links and display backlinks, Zed replaces not just VS Code but potentially the note-taking applications too. One editor for code and notes and everything connected by links.

This is the dream. The dream is contingent on Zed’s extension API becoming powerful enough. The extension API is young. The dream is patient.

“Just need to wait until Zed’s plugins are powerful enough to understand backlinks, and it will also replace Obsidian and NotePlan. One editor. All the links. All the code. All the notes.”
— riclib, describing the endgame

The Nathan Sobo Arc

Nathan Sobo’s career is a parable:

1. Built Atom at GitHub — an Electron-based editor, one of the first desktop apps built on web technology
2. Atom was beautiful, extensible, and slow
3. VS Code, also Electron-based but built by a company with more resources, killed Atom
4. Microsoft acquired GitHub, and Atom was deprecated in favour of VS Code
5. Sobo left, processed what happened, and built Zed — native, fast, the anti-Electron editor

The lesson is not that Electron is bad. The lesson is that someone who built one of the most famous Electron applications concluded, after years of living with it, that native was the answer. The lesson is that the person with the most experience building Electron editors chose not to build another one.

Measured Characteristics

Year announced:                          2022
Creator:                                 Nathan Sobo (previously: Atom at GitHub)
Written in:                              Rust (native, no runtime, no GC)
Startup time:                            <200ms (below perceived instantaneity)
VS Code startup time:                    2-4 seconds
Memory usage:                            80-150 MB
VS Code memory usage:                    800-1500 MB
Memory ratio (VS Code : Zed):            ~10:1
Extensions available:                    hundreds (growing)
VS Code extensions available:            40,000+
Extensions that matter (language, AI):   present
Extensions that are missed:              specific, niche, coming
riclib installations:                    2 (Zed + Zed Preview)
The condition for full migration:        backlinks in extensions
Applications Zed could replace:          VS Code, possibly Obsidian, possibly NotePlan
Laptop fan when Zed is open:             silent
Laptop fan when VS Code is open:         audible
What Zed remembered:                     that software should be fast
What Electron forgot:                    that software should be fast

See Also

• VS Code — The editor Zed is replacing. Not because VS Code is bad, but because VS Code is Electron.
• Electron — The framework Zed rejected. Built by the same person who helped popularize it.
• Rust — The language that makes Zed fast. Not a trend. An engineering choice with measurable consequences.
• Obsidian — The note-taking app that Zed could replace if backlinks arrive.
• NotePlan — The other note-taking app in riclib’s workflow. Same backlinks condition applies.
• vi — The editor that was always this fast, because the editor was always this simple. Zed is the first modern editor to approach vi’s speed without vi’s minimalism.
• VT100 — Still faster than Zed. But Zed is the closest anyone has come in forty-eight years.