Zed is now available on Windows

Original Article ↗ Hacker News Discussion ↗

Windows Release & Packaging

  • Windows build is now public; some users report slow startup (up to ~10s) and x86_64-only binaries, with ARM users compiling from source and asking for official aarch64 builds.
  • winget entry initially lagged behind; packaging updates are in progress.
  • Some basic Windows conventions don’t work yet (ALT+F menus, ALT+SPACE system menu), reinforcing the sense that the UI behaves more like a game than a native Win32 app.

GPU Rendering, Latency & Remote Use

  • Many users praise Zed’s responsiveness and “feel”, especially versus VS Code; comparisons liken it to moving from 40 FPS with input lag to 120 FPS.
  • Others say they barely notice editor latency in any tool and find the frame-rate marketing odd, prioritizing file-size handling and startup more.
  • Zed requires a DirectX‑capable GPU; over RDP or on systems using Microsoft’s Basic Render Driver it warns of “awful performance”. Some report acceptable performance even in VMs, but input lag over RDP can be noticeable.
  • GPU dependence causes issues on Linux suspend/resume for some.

Binary Size, Static Linking & Resource Debates

  • Windows install is ~400 MB (Linux binary ~300+ MB). A large fraction is statically linked code, tree-sitter grammars, custom GPU UI, and WebRTC for collaboration.
  • Heated subthread debates static vs dynamic linking, with one side calling 400 MB “ridiculous bloat” and the other arguing storage is cheap and static linking simplifies deployment and reduces runtime complexity.
  • There’s clarification that large binaries are demand-paged, so not all code lives in RAM at once.

Font Rendering & Displays

  • Font rendering—especially on non‑HiDPI Linux/Windows monitors—is a major complaint. Lack of subpixel RGB anti-aliasing makes text appear fuzzy for many on 1080p/1440p displays; some report literal headaches.
  • Recent Linux patches improved greyscale AA; Windows uses DirectWrite and is seen as better than prior Linux builds but still only “decent”.

Language Servers, Features & Performance

  • TypeScript and Python experiences are mixed: editor is fast but “go to definition” and autocomplete can be slower than VS Code/Cursor on large projects.
  • Explanations include: VS Code’s tight, non‑LSP TS integration; Zed using stdin/stdout for LSP IPC instead of pipes/sockets; and choice of pyright vs Pylance.
  • C++ support and C# extension work are seen as less mature than VS Code / JetBrains.
  • Some basics are still rough: earlier UTF‑8‑only limitations (now partly addressed), stale buffers on external file changes, project‑wide search UI perceived as weaker than VS Code’s.

AI & Collaboration vs Competitors

  • Users like that Zed can be used fully without AI and that AI features can be disabled globally.
  • Zed’s “Predict Edit” / Super Complete is criticized as technically weaker than Cursor/Windsurf, which embed richer language‑server–driven context; some question charging for it.
  • Collaboration stack (voice, shared editing, even screen-sharing via WebRTC) explains part of the size but is appreciated by some and viewed as scope creep by others.

Workflow Integration & Adoption Blockers

  • Devcontainer support, better Docker/toolbox integration, and per‑project env handling are key blockers for teams that rely on containerized dev environments.
  • Some dislike silent auto-download of third-party language servers/extensions; there is a setting to disable auto-install, but behavior and control granularity are considered unclear.
  • A notable UX pitfall: “Delete” vs “Trash” in the file menu—“Delete” skips trash and isn’t undoable—has led to data loss for at least one user; placement and semantics are seen as dangerous.
  • Overall sentiment: strong enthusiasm for the speed and feel, but many hold off full migration due to missing polish, language tooling gaps, Windows quirks, and ecosystem maturity.