Zed on Linux Is Here

Overall reception

• Many are excited to have a fast, native, open‑source alternative to Electron editors, especially on Linux.
• Others are unconvinced it offers enough over VS Code / JetBrains / Neovim to justify switching, at least yet.

Killer features & UX

• Frequently praised for:
  • Very fast startup and editing; feels close to Vim/Neovim/Sublime on many setups.
  • Clean, well‑designed UI and typography; some care a lot about this versus VS Code’s look.
  • “Multi‑buffers” / multi‑file search: search results open as editable mini‑buffers so you can edit across many files from one view.
  • Good pane management, outline view, integrated terminal, different fonts/sizes for terminal vs editor, “magnify current pane”.
• Critiques:
  • Default dark themes and font rendering on Linux sometimes low‑contrast or blurry.
  • Default auto‑format‑on‑save surprises some, especially in legacy or mixed‑style repos.
  • Vim mode exists but lags real Vim/Neovim and JetBrains/VS Code emulations for some workflows.

Performance vs other editors

• Compared to VS Code:
  • Many say VS Code is already “fast enough” on typical projects; Zed’s extra speed feels marginal.
  • On big monorepos / many open windows, VS Code’s Electron and language servers can become very slow and memory‑hungry; Zed feels lighter here.
• Compared to terminal editors:
  • Neovim/Helix users still find Zed slower in latency‑sensitive scenarios, but it’s among the fastest GUI editors they’ve tried.
• Some Linux users report serious jank (low FPS, high CPU on mouse move, laggy resizing) tied to GPU/driver/Wayland setups.

Language support & tooling

• Very good experience reported for Rust and decent for C++; several say Zed feels “systems‑language first.”
• JS/TS support is notably behind VS Code:
  • Autocomplete and diagnostics feel worse; ESM imports and TS server integration are flaky for some.
• Uses Pyright for Python; some prefer Pylance/Ruff and dislike current defaults.
• Plugin story: extensions exist, but Rust‑ and Wasm‑based plugins are seen as heavier and less approachable than Python/Lua ecosystems.

Collaboration & business model

• “Collaboration‑first” positioning (channels, calls, shared editing) is highlighted by the team and some users love it, especially versus unreliable VS Code Live Share.
• Others see editor‑embedded collaboration as niche or unwanted “noise”; they prefer git + screen sharing and want an easy way to turn all collab features off.
• Monetization plan: core editor free, paid network/collab features; some worry VC backing will eventually push enshittification, others find this model acceptable if the editor remains fully usable offline.

Installation, packaging & security

• Huge debate around the recommended curl | sh installer:
  • Critics: bad UX and security practice; hides where files go, bypasses distro packaging and signatures, complicates updates.
  • Defenders: common pattern, script is short and readable, runs as user, and there are alternative methods.
• Alternatives exist: distro packages (Arch, NixOS, Gentoo, others), manual tarball install, and early Flatpak support (not yet on Flathub). Many request an official Flatpak/Snap to avoid scripts entirely.
• Separate concern: Zed auto‑downloads and runs language servers and tools (Node, rust‑analyzer, JSON LSP, etc.) without a clear global opt‑out, which breaks on NixOS and is unacceptable for some security‑sensitive or corporate environments. Work to make this configurable is in progress.

Platform‑specific issues

• Linux:
  • Requires Vulkan 1.3 and a “physical” (non‑pure‑software) GPU; some older or unusual setups fail.
  • File dialogs depend on XDG desktop portals; missing/incorrect portal setup breaks “Open file/project”.
• WSL/WSLg:
  • Several reports of crashes or no UI; support appears immature.
• Overall, many like Zed enough to keep it as a secondary editor and plan to revisit as language support, plugins, and platform polish improve.