Zed Editor: The Rust-Powered Code Editor That Makes VS Code Look Slow

VS Code Is Great, But Have You noticed It’s Kinda… Slow?

I love VS Code. I’ve used it for 6 years. But let’s be real: it takes 2 seconds to launch, uses 500MB of RAM just to open a single Markdown file, and searching a 10,000-file repo feels like watching paint dry. Also, have you looked at the Activity Monitor while running VS Code? It’s using 30% CPU to do nothing.

Enter Zed. It’s a code editor built from scratch in Rust, by the original Atom editor team (Nathan Sobo and friends). It launches in 0.3 seconds, uses 45MB of RAM, and can search 100,000 files in milliseconds. It’s so fast it feels like cheating.

I switched 2 months ago. My M3 Max sounds like a gentle breeze instead of a jet engine. Also, my battery life improved by 2 hours. That’s not an exaggeration — I timed it.

What Is Zed, Really? (And Why Should You Care?)

Zed is a Rust-native, GPU-accelerated code editor designed for speed. No Electron, no Chromium, no JavaScript runtime — just native Rust code talking directly to your OS’s GPU APIs.

Key facts:

Built by the Atom team: Nathan Sobo (Atom’s tech lead) left GitHub/Microsoft and started Zed. He took everything he learned building Atom and did it right this time.
Open-source (since 2024): The entire codebase is on GitHub (GPLv3 license). 35,000+ stars and climbing.
Collaborative editing built-in: Multiple users can edit the same file in real-time, like Google Docs for code. No extensions needed.
GPUI framework: Zed uses its own GPU-accelerated UI framework (GPUI) written in Rust. It’s open-source too — you can use it to build your own apps.

The philosophy is simple: editors should be instant. Every keystroke should feel like it’s modifying the screen at the speed of light. If there’s a 10ms delay, that’s a bug.

Why Rust? (The “Why Not C++ or Electron?” Question)

Nathan Sobo gave a talk about this, but here’s the summary:

Zero-cost abstractions. Rust lets you write high-level code that compiles to machine code as fast as C. No GC pauses, no runtime overhead.
Memory safety without garbage collection. You can’t have a segfault in safe Rust. That means Zed rarely crashes (unlike Atom, which crashed if you looked at it wrong).
Fearless concurrency. Rust’s ownership model makes multi-threading safe and easy. Zed uses all your CPU cores for things like syntax highlighting, file searching, and extension execution.
GPU integration. Rust has excellent Vulkan/Metal/Direct3D bindings. Zed’s GPU renderer is written in Rust, which means rendering is as fast as a native C++ app.
Package management that doesn’t suck. Cargo is actually good. Compare that to npm (which installs 10,000 dependencies to print “hello world”).

Also, side note: the Zed team contributes to Rust itself. They’ve pushed performance improvements to the Rust compiler that make all Rust code faster. That’s how committed they are.

The GPU-Accelerated Rendering Pipeline (It’s Not Just “Uses the GPU”)

Zed’s rendering pipeline is a masterpiece of engineering. Here’s how it works:

Step 1: Text Shaping (Done on CPU, but Fast)

When you type text, Zed uses HarfBuzz (same library Chrome uses) to shape the text — that means ligatures, emoji, and complex scripts (Arabic, Devanagari, etc.) render correctly.

But here’s the trick: Zed caches shaped text. If you type the same character sequence again, it pulls the shaped glyphs from cache instead of re-shaping. Result: near-zero latency for text input.

Step 2: Glyph Upload to GPU (Once per Font)

Instead of rendering glyphs on the CPU (like VS Code does with Electron’s canvas), Zed uploads glyphs to the GPU as a texture atlas. That means rendering 10,000 glyphs is just one GPU draw call.

VS Code, by contrast, uses Chromium’s text rendering — which is good, but it’s still a web browser rendering text. There’s layers of abstraction between your keystroke and the pixels on screen.

Step 3: Syntax Highlighting (Tree-sitter + GPU)

Zed uses Tree-sitter for syntax highlighting. Tree-sitter is a incremental parsing library that can reparse your code in milliseconds after every keystroke.

Here’s the workflow:

You type a character.
Tree-sitter incrementally reparses the affected part of the syntax tree (takes ~1ms).
Zed updates the syntax highlighting for only the changed tokens (not the whole file).
The GPU re-renders only the changed glyphs.

Result: syntax highlighting that’s instant even in 100,000-line files. VS Code starts lagging at 5,000 lines.

Step 4: Compositing (All on GPU)

Everything — text, UI elements, minimap, breadcrumbs, collaborative cursors — is composited on the GPU. No CPU involvement after the initial upload.

Zed can maintain 165 FPS while you’re scrolling through a 50,000-line file. VS Code drops to 30 FPS with a 5,000-line file.

Performance Numbers (Receipts, Because I Know You Want Them)

I ran some completely unscientific but still relatable benchmarks on my M3 Max (64GB RAM, macOS 15.4.1):

Startup Time (Cold Launch, No Extensions)

Editor	Startup Time
Zed	0.3s
VS Code	1.8s
Cursor	2.1s
Neovim (lazy.nvim)	0.15s (but you have to configure everything yourself)
Sublime Text	0.4s

Winner: Zed. It launches before you can blink. VS Code is 6x slower.

Memory Usage (Idle, 10 Open Files, Medium-sized Repo)

Editor	Memory Usage
Zed	45MB
VS Code	480MB
Cursor	520MB
Neovim	25MB (but again, you configured it yourself)
Sublime Text	60MB

Winner: Zed. 45MB is nothing. You could have 50 Zed windows open and still not max out your RAM. VS Code uses 10x more memory to do the same thing.

File Search (10,000 Files in Repo, Fuzzy Search)

Editor	Search Time
Zed	8ms
VS Code	450ms
Cursor	520ms
Neovim (telescope)	25ms
Sublime Text	15ms

Winner: Zed. 8 milliseconds. That’s faster than the time it takes for your brain to register that you’ve pressed a key. VS Code takes 450ms — you can literally see the search results “pop in” with a delay.

Syntax Highlighting Latency (Typing in a 10,000-Line File)

Editor	Highlighting Latency
Zed	1ms
VS Code	35ms
Cursor	40ms
Neovim (treesitter)	2ms
Sublime Text	5ms

Winner: Zed. 1ms is imperceptible. You literally cannot tell there’s any delay. VS Code has a noticeable lag when typing in large files.

Key Features (That Actually Matter, Unlike “AI-Powered Code Suggestions” That Are Wrong 50% of the Time)

Zed isn’t just fast — it has all the features you actually need:

1. Collaborative Editing (Built-In, No Extensions)

This is Zed’s killer feature. You can share your editor with another Zed user, and you both can edit the same file in real-time. It’s like Google Docs for code.

How it works:

Click the “Share” button (top-right corner).
Send the link to your teammate.
They join, and you can see each other’s cursors, selections, and edits in real-time.
Voice chat is built-in too (uses WebRTC, no third-party services).

Why it’s better than VS Code Live Share:

No extension needed (it’s built-in).
Lower latency (direct P2P connection, no relay servers).
Works with any language (VS Code Live Share sometimes breaks with certain extensions).

I’ve pair-programmed with 3 different people using Zed’s collaboration. It’s magical. Also, you can “follow” someone’s cursor, so you’re always looking at the same code.

2. Multi-Buffer Editing (Edit Multiple Files at Once)

Zed lets you create a “multi-buffer” — a temporary buffer that contains the content of multiple files. You can edit all of them simultaneously, then save all at once.

Use case: You’re refactoring a function that’s used in 10 files. Instead of opening each file individually, you:

Search for the function name.
Select all 10 files.
Zed opens a multi-buffer with all 10 files.
You make the change once, and it applies to all 10 files.
Save all.

It’s like “Find and Replace” but you can see the context and make nuanced changes.

3. Vim Mode (First-Class Support, Not an Afterthought)

Zed has a built-in Vim emulation mode that’s actually good. It supports:

Normal, insert, visual, and command modes.
Custom keybindings (via ~/.config/zed/keymap.json).
Integration with Zed’s other features (you can use Vim motions to select files in the file picker, for example).

I’m a Vim user, and I’ve been using Zed’s Vim mode for 2 months without missing neovim. That’s high praise.

4. Language Server Protocol (LSP) Support

Zed supports the Language Server Protocol (LSP), which means:

Autocomplete (via the language server).
Go to definition.
Find all references.
Rename symbol across files.
Diagnostics (errors/warnings inline).

It works with every language that has an LSP server (which is most of them at this point). I use it with Rust, Python, TypeScript, and Go — all work perfectly.

Zed uses Tree-sitter (the same library Neovim uses) for code navigation:

Outline view: See all functions/classes in a file, click to jump.
Symbol rename: Rename a function, and it updates all references.
Syntax-aware selection: Press Cmd+Shift+Right to expand selection by syntax node (not by word/line).

It’s significantly better than VS Code’s regex-based code navigation.

6. Integrated Terminal (Actually Good, Unlike Some Editors)

Zed has a built-in terminal that’s… actually good. It uses Alacritty’s GPU renderer (the same one Ghostty uses), so it’s fast. Supports ligatures, emoji, and 24-bit color.

You can have multiple terminal panes, split them, rename them, etc. It’s not as feature-rich as Ghostty, but it’s good enough that I don’t feel the need to open a separate terminal app.

7. Git Integration (Built-In, No Extensions)

Zed shows git diffs inline (red/green highlights for deleted/added lines). You can:

See which lines you’ve changed (inline gutter indicators).
Stage/unstage hunks (selections of changed lines).
Commit, push, pull (via the integrated terminal, or via the git panel).
Resolve merge conflicts (with a nice 3-way merge UI).

It’s not as full-featured as VS Code’s GitLens extension, but it covers 90% of use cases.

How to Install (It’s Stupid Easy)

macOS (Homebrew — Because You Have Homebrew Installed, Right?)

1	brew install --cask zed

That’s it. Launch it from Spotlight.

Linux (AppImage — Because Linux Users Love AppImages)

# Download the latest AppImage
wget https://github.com/zed-industries/zed/releases/latest/download/zed-linux-x86_64.AppImage

# Make it executable
chmod +x zed-linux-x86_64.AppImage

# Run it
./zed-linux-x86_64.AppImage

For Arch users (of course you use Arch):

1	yay -S zed

Windows (Finally!)

Zed added Windows support in late 2025. Download the installer from zed.dev/download, run it, and follow the prompts.

Note: Windows support is still in beta. Some features (like collaborative editing) might be buggy. But it works well enough for daily use.

Build from Source (For Nerds Who Want to Tweak Everything)

# Clone the repo
git clone https://github.com/zed-industries/zed.git
cd zed

# Install Rust (if you haven't already)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Install dependencies (macOS)
brew install cmake gettext

# Install dependencies (Linux)
sudo apt install cmake libxkbcommon-dev libwayland-dev libvulkan-dev

# Build Zed
cargo build --release

# Run it
./target/release/zed

This takes about 20 minutes on an M3 Max. Grab a coffee.

Basic Configuration (TOML, Because JSON Is for People Who Hate Themselves)

Zed’s config file is located at ~/.config/zed/settings.json (yes, JSON, not TOML — Nathan Sobo says JSON is fine, fight me).

Here’s my config (feel free to steal it):

{
  "theme": "catppuccin-mocha",
  "base_keymap": "Vim",
  "language_overrides": {
    "Rust": {
      "tab_size": 4,
      "hard_tabs": true
    },
    "Python": {
      "tab_size": 4,
      "hard_tabs": false
    },
    "TypeScript": {
      "tab_size": 2,
      "hard_tabs": false
    }
  },
  "vim_mode": true,
  "relative_line_numbers": true,
  "soft_wrap": "preferred_line_length",
  "preferred_line_length": 100,
  "buffer_font_size": 14,
  "buffer_font_family": "Fira Code",
  "terminal_font_size": 13,
  "terminal_font_family": "Fira Code",
  "git": {
    "inline_blame": true
  }
}

It’s not as configurable as Neovim (nothing is), but it covers 95% of what I need.

Zed vs. The World (Comparisons Nobody Asked For, But Here They Are Anyway)

Zed vs. VS Code

Feature	Zed	VS Code
Startup time	0.3s	1.8s
Memory usage	45MB	480MB
Search speed	8ms	450ms
Syntax highlighting	Tree-sitter (instant)	TextMate grammars (laggy in large files)
Collaborative editing	Built-in	Extension (Live Share)
Extensions	Growing (500+)	Massive (50,000+)
Language support	LSP (all languages)	LSP + extensions
Customizability	Moderate	Extreme
Stability	Beta (some bugs)	Stable

Verdict: Zed is faster, lighter, and has better collaboration. VS Code has more extensions and is more stable. If you’re OK with a few bugs and don’t need niche extensions, switch to Zed.

Zed vs. Neovim

Feature	Zed	Neovim
Startup time	0.3s	0.15s
Memory usage	45MB	25MB
Configuration	JSON (easy)	Lua (hard, but powerful)
Collaborative editing	Built-in	No (unless you use CoVim, which is janky)
GUI	Yes (native)	No (unless you use Neovide, etc.)
Learning curve	Low	High
Customizability	Moderate	Infinite

Verdict: If you’re already a Neovim user, you’ll probably stick with Neovim. If you want Neovim’s speed with a GUI and collaboration, Zed is the answer.

Zed vs. Cursor

Feature	Zed	Cursor
Startup time	0.3s	2.1s
Memory usage	45MB	520MB
AI features	No (use Aider or Copilot extension)	Yes (tab completion, chat, etc.)
Collaborative editing	Built-in	No
Cost	$0	$20/month

Verdict: If you want AI features, Cursor is better. If you want speed and collaboration, Zed is better. I use Zed + Aider (in the terminal) for AI assistance.

The “Gotchas” (Because Nothing Is Perfect, Especially Software Written in Rust)

Extension ecosystem is small. VS Code has 50,000 extensions. Zed has ~500. If you rely on a niche extension, it might not exist in Zed yet. (But the extension API is stable, and more are being added every week.)
Windows support is beta. If you’re on Windows, expect some bugs. Nathan Sobo says Windows support will be stable by end of 2026, but for now, it’s “daily drivable” but not perfect.
No debugger UI. VS Code has an excellent debugger UI (variables, call stack, breakpoints, etc.). Zed doesn’t have a debugger UI yet — you have to use CLI tools (gdb, lldb, etc.). It’s coming in 2026, but for now, it’s a pain point.
No Jupyter Notebook support. If you’re a data scientist, Zed doesn’t support Jupyter Notebooks yet. VS Code is better for data science.
Rust is hard. If you want to contribute to Zed, you need to learn Rust. It’s not as hard as people say, but it’s harder than JavaScript.

Should You Actually Switch? (The Honest Answer)

Yes, if:

You care about performance (startup time, memory usage, search speed).
You want built-in collaborative editing (pair programming, code reviews, etc.).
You’re OK with a smaller extension ecosystem.
You don’t need a debugger UI (or you’re OK using CLI debuggers).
You’re on macOS or Linux (Windows support is still beta).

Maybe not, if:

You rely on niche VS Code extensions that don’t exist in Zed.
You need a debugger UI (wait for Zed v1.0 in 2026).
You’re a data scientist who needs Jupyter Notebook support.
You’re on Windows and need 100% stability (wait a few months).

Final Thoughts (Before I Run Out of Steam)

Zed is the editor I didn’t know I needed. I spent years putting up with VS Code’s slowness because “that’s just how editors are”. Then I tried Zed, and now I can’t go back.

It’s fast, it’s lightweight, it has built-in collaboration, and it’s open-source. Also, it’s built by people who actually use it (not a corporation trying to sell you Copilot subscriptions).

The extension ecosystem is small, but it’s growing fast. By the end of 2026, I bet Zed will have most of the extensions people actually use.

Now if you’ll excuse me, I need to go refactor my Rust project in Zed. It’s 3am, I’ve had too much coffee, and the collaborative editing is calling my teammate in a different time zone.

P.S. Yes, I know I sound like a shill. I’m not affiliated with Zed in any way — I just really like not waiting 2 seconds for my editor to launch.

P.P.S. 35,000+ GitHub stars don’t lie. Go star it at github.com/zed-industries/zed and join the Discord. The community is small but helpful.

P.P.P.S. If you’re a VS Code developer reading this: I still love you. But please, rewrite VS Code in Rust. Or at least make it not use 500MB of RAM to open a Markdown file.