Zed Editor Finally on Linux and It Is Absurdly Fast
I have a soft spot for editors that do not make me wait. Every millisecond of lag between hitting a key and seeing the character show up is a tiny tax on my attention. Over the years I have bounced between editors trying to find one that feels as responsive as a terminal window. Zed is the closest I have seen, and now that it runs natively on Linux, I think a lot of people are about to ask why they put up with slower tools for so long.
Zed comes from the same team that built Atom, the editor GitHub acquired and later shut down. That experience taught them something valuable about what developers actually want. Atom was extensible to a fault. It was slow, it ate RAM like candy, and every plugin added another layer of abstraction between you and your code. Zed goes the opposite direction. It is written in Rust, built around a GPU accelerated rendering pipeline, and designed from the ground up to feel instant. It also happens to be open source and free, at least for now.
What makes Zed feel different
Three things stand out when you open Zed for the first time.
First, launch time. Zed opens in under a second on a cold start. Most editors I have used in the last few years take 2-4 seconds before they are usable, and the heavyweights like older VS Code builds can take 8-10. Zed opens, the cursor is blinking, and I am typing before I have finished lifting my hand off the launcher. That alone is enough to make me pay attention.
Second, rendering. The text grid is GPU accelerated, which is unusual for a code editor. Most editors render text on the CPU using a library like Skia or a hand-rolled layout engine. Zed pushes the entire text grid to the GPU and lets it redraw independently of the main thread. The practical effect is that scrolling through a 50,000-line file is the same speed as scrolling through a 500-line file. There is no stutter, no lag spike on long lines, and no visible redraw flicker.
Third, input latency. Zed measures itself against a target of 8ms keystroke-to-pixel. On my desktop with a 240Hz monitor, I cannot tell the difference between Zed and a raw terminal. The keyboard feels like it is talking directly to the screen. On a 60Hz laptop it is still noticeably snappier than VS Code, which is the comparison most people will draw.
What you give up to get that speed
There are real costs to the design choices that make Zed feel fast.
- Extensibility is narrower than VS Code. The plugin system and extension API exist, but the available extensions are a fraction of what VS Code offers. If you depend on a specific VS Code extension for your daily workflow, do not assume the Zed equivalent exists. Most popular languages have decent support (Python, Rust, Go, TypeScript, Markdown all work well). Niche stuff often does not.
- Debugging is thinner. Zed has a built-in debugger for Rust and a basic debugger for other languages via the Debug Adapter Protocol (DAP, a standard interface that lets editors talk to language-specific debuggers). It works, but it does not have the polish of VS Code’s debugger, which has been iterated on for almost a decade. If you spend most of your day in a debugger, this is a real cost.
- Windows support is not stable. Zed is on macOS and Linux. Windows support is in development but not ready for daily use. The team has said Windows is a priority and there are community builds, but they are not the same product.
- LSP implementation is solid but not mature. Zed uses LSP (Language Server Protocol, the same standard most editors use to provide features like autocomplete and go-to-definition). The implementation works but you will occasionally hit LSP edge cases where autocomplete glitches or a long-running language server slows the editor down. These are rare but they happen.
The pattern is consistent. Zed is fast because it does less. Every feature you add back is a feature that costs some of the speed. The team has made the trade-off on the speed side. If your trade-off is different, Zed is not your editor.
How Zed compares to what you are probably using today
Most Linux developers I know use either VS Code, Neovim, or JetBrains IDEs. Here is how Zed stacks up against each.
Compared to VS Code, Zed is faster to launch, faster to type in, and uses less memory. Zed loses on extensions, debugging, and Windows support. If you are a VS Code user with a thin extension setup, Zed will feel like a free upgrade. If you depend on specific VS Code extensions, Zed is a downgrade until those extensions exist.
Neovim is faster on text manipulation but Zed wins on rendering (Neovim does not use the GPU by default), Zed is easier to configure for new users, and Zed has built-in collaboration. Zed loses on customizability, modal editing depth, and terminal integration. If you are a Neovim user with a heavily customized config, Zed is not going to replace your setup. If you are a Neovim user who has been wanting a GUI editor that does not slow you down, Zed is the closest thing I have seen.
JetBrains IDEs are still the better tool for projects that need deep language understanding. JetBrains understands your code at a deeper level than any LSP-based editor does, and that gap is real. If you are doing heavy refactoring work in Java or Kotlin or Python, JetBrains is the better tool. Zed wins on speed and on the things that do not require semantic code understanding.
Trade-offs
Zed is free for personal use today. The team has said there will eventually be a paid tier for teams and enterprise features (collaboration, centralized settings, audit logs). If you are an individual developer, you will not pay for Zed. If you are part of a 50-person engineering team that needs centralized extension management and SSO, you will pay when the paid tier lands. Pricing has not been announced.
Zed’s collaboration features are genuinely good. You can share your editor with another person over the internet, with cursor positions and selections synced in real time. This is the feature that came out of the original Atom Teletype work. If you do pair programming or remote code review, this is a real productivity win over screen sharing. The latency is low enough that it feels like you are sitting at the same desk.
The plugin store will grow over time but it is the slowest part of the project today. If you are evaluating Zed for daily use, check the plugin list for your specific tools. Most developers will find what they need. A few will not. The team is actively working on plugin quality and the API is stable enough that motivated developers can build what they need themselves.
If you are a Vim or Emacs user, Zed has vim keybindings and an emacs mode. Neither is as deep as the real thing, but the vim mode is good enough that I have not felt the urge to switch back. If you are a die-hard Neovim user with a heavily customized config, Zed is not going to replace your setup. It might complement it for specific tasks where GPU rendering matters.
If you only do one thing from this article, open Zed on your Linux box and type for ten minutes. If the input latency does not sell you, nothing I write here will. The performance is the point. Everything else is a tradeoff against that.