Zed ist jetzt für Windows verfügbar

• Der Code-Editor Zed ist jetzt offiziell für Windows verfügbar
• Rendering mit DirectX 11, für das Text-Rendering wird DirectWrite verwendet, um ein für Windows typisches visuelles Erlebnis zu bieten
• Direkte Integration mit Windows Subsystem for Linux (WSL) und Unterstützung für SSH-Remote-Zugriff stärken die Remote-Entwicklungsumgebung
  • Im WSL-Terminal kann ein Ordner direkt mit dem Befehl zed geöffnet werden
  • Auch innerhalb von Zed wird das Hinzufügen der gewünschten WSL-Distribution unterstützt, indem File > Open Remote oder in der Befehlspalette project: open remote ausgewählt wird
  • Für die Verbindung zu entfernten Linux-Servern gibt es die Option Connect New Server
  • Die Datei-I/O-Verarbeitung in WSL- oder SSH-Umgebungen erfolgt über den leichtgewichtigen Remote-Server-Prozess von Zed (wsl.exe/ssh.exe)
  • Dateibearbeitung, git-Integration, Terminal, Tasks, Language Server, Debugger und andere Kernfunktionen funktionieren auch in Remote-Umgebungen vollständig
• Erweiterungen und WebAssembly-Integration
  • Erweiterungen für Windows können sofort ohne zusätzliche Konfiguration genutzt werden
  • Bei der Entwicklung neuer Erweiterungen ist keine Windows-spezifische Sonderbehandlung erforderlich
  • Zed-Erweiterungen basieren auf WebAssembly Components und können über die WASI-Schnittstelle sandboxed auf das Dateisystem zugreifen
  • Die Umwandlung von Dateipfaden übernimmt Zed automatisch, sodass sich ohne den Aufwand unterschiedlicher Pfade unter Windows und Unix entwickeln lässt
• AI-Funktionen und weitere Punkte
  • Alle AI-Funktionen von Zed, darunter AI-gestützte Bearbeitungsvorhersagen und ACP (Agent Client Protocol)-Engine-Agents, werden unter Windows und in Remote-Umgebungen (WSL/SSH) vollständig unterstützt
  • Claude Code kann direkt über ACP genutzt werden
  • 14 Tage kostenlose Testversion von Zed Pro oder Nutzung mit einem persönlichen API-Key möglich
• Wie bei Mac und Linux gibt es auch für die Windows-Version wöchentliche Updates; zudem nutzen mehrere Zed-Ingenieure Windows als primäre Entwicklungsumgebung, und es gibt dauerhaft ein dediziertes Windows-Entwicklungsteam

[GN⁺]

Hacker-News-Kommentare

• Ich möchte anmerken, dass grundlegende Windows-OS-Tastenkürzel nicht funktionieren. Zum Beispiel öffnet ALT+F nicht das Dateimenü, und ALT+LEERTASTE zeigt auch nicht das System-Kontextmenü an (Maximieren, Minimieren, Schließen usw.). Wegen der Eigenschaften des DirectX-Rendering-Backends wirkt es so, als würde die Anwendung eher wie ein Videospiel gerendert als wie ein nativer Win32-Prozess. Überraschend ist auch, dass das Installationsverzeichnis nach der Installation über 400 MB groß ist. Wenn man bedenkt, dass VSCode etwa 380 MB benötigt, glaube ich zwar, dass es keine Electron-App ist, frage mich aber, was da alles enthalten ist. Ich dachte immer, Rust-Apps seien leichtgewichtig, aber die Installationsgröße fühlt sich fast wie das Aufblähen von Binärdateien/Abhängigkeiten auf Java-Niveau an
  • Ein Rust-Hello World-Binary ist größer als Git. Es ist zwar immer noch kleiner als Java oder Electron, aber wirklich klein ist es nicht
  • PSPad ist 40 MB groß und wird immer noch aktualisiert, obwohl es Legacy-Software ist. Notepad++ ist 17 MB groß. Dass ein modernes, kompiliertes Spitzenprojekt in Rust 400 MB belegt, halte ich für absurd
  • Die aufgeblähte Installationsgröße von über 400 MB dürfte viele Leute abschrecken. Es braucht schnell eine Erklärung, warum dieser Platzbedarf nötig ist
  • Auch wenn es kein Electron ist, fühlt es sich an, als wäre standardmäßig die Hälfte von Electron, nämlich Node.js, enthalten. Die meisten LSPs basieren auf .js, und die Erweiterungen sind WASM. VSCode legt Erweiterungen in ein separates Konfigurationsverzeichnis, bei Zed steckt alles im Installationsverzeichnis
  • Zur Info: Es ist durchaus möglich, in einem Fenster gleichzeitig einen Grafik-Kontext und eine Win32-Menüleiste zu haben
• Ich frage mich, ob Zed Subpixel-Schrift-Rendering implementiert hat. Ich erinnere mich, dass der UI-Renderer früher auf die HiDPI-Displays des Mac ausgelegt war, wodurch Linux- (und Windows-)Nutzer mit LoDPI-Displays unter verschwommenen Schriften leiden mussten
  • Ob es Subpixel-Rendering ist, weiß ich nicht, aber nach den jüngsten Patches ist das Font-Rendering unter Linux deutlich besser geworden relevanter Link
  • Das würde mich auch interessieren. Soweit ich weiß, nutzt Zed auf dem Mac CoreText und unter Windows DirectWrite. Erledigt CoreText nicht ohnehin alles?
  • Der Windows-Build rendert mit DirectX 11 und verarbeitet Text mit DirectWrite, was sich sehr nach Windows anfühlt. Das Font-Rendering von DirectWrite nutzt das Windows-Subpixel-Rendering. Auf meinem Monitor sah es gut aus (besser als unter Linux). Es wirkt, als hätten sie dieses Problem von Anfang an mitbedacht und sauber gelöst
  • Ich nutze unter macOS einen externen 1440p-Monitor, und die Schrift war wirklich furchtbar. Auf dem Retina-Display des Laptops war es okay, aber auf dem externen Monitor so verschwommen, dass ich davon Kopfschmerzen bekam
  • Ich habe auf einem 1440p-Monitor ebenfalls mit verschiedenen Schriften getestet, und es war durchschnittlich. Ich glaube aber nicht, dass das ein Zed-Problem ist, sondern dass das Schrift-Rendering von Windows generell nicht besonders gut ist. Bei VSCode ist es ähnlich. Wenn man hochwertiges Font-Rendering will, scheint ein 4K- oder höher auflösender Bildschirm die richtige Antwort zu sein
• Ich habe Zed mehrere Monate als Haupteditor genutzt, bin aber kürzlich wieder zu VSCode zurückgekehrt. Dafür gibt es zwei Gründe: Einer war mein eigener Fehler, beim anderen ist unklar, wo genau das Problem lag. 1. Ich habe spät nachts noch programmiert, dann vor dem Check-in eine Datei umbenannt und versehentlich die neue Version gelöscht, wodurch ich mehrere Stunden Arbeit verloren habe. Im Rechtsklick-Menü von Zed stehen Delete und Trash direkt nebeneinander, und Delete löscht sofort ohne Papierkorb. Ctrl+Z ist auch noch nicht implementiert, daher gibt es ohne Backup keine Wiederherstellungsmöglichkeit (es war auch noch nicht in die Versionsverwaltung eingecheckt). 2. In einem Rust-Workspace wurden mir bei einem bestimmten Crate im Editor überhaupt keine Fehler oder Warnungen angezeigt. Ich habe allerlei Einstellungen ausprobiert, ohne Erfolg, dann VSCode geöffnet, und dort funktionierte es ohne besondere Konfiguration
  • Das erinnert mich an die macOS-Touch Bar. Im Commit-Verwaltungsmenü stand Cancel direkt neben Force Push
  • Dass Ctrl+Z in Zed nicht funktioniert, ist ein kaum zu glaubender Mangel bei einer so wichtigen Grundfunktion
  • Ich frage mich, wie man einen Editor mit solchen fehlenden Basisfunktionen überhaupt nutzen soll. Was genau ist der Vorteil?
• Zed sieht wirklich großartig aus und fühlt sich auch tatsächlich hervorragend an. Ich habe es kurz unter Linux benutzt, und dieses Gefühl des Editors lässt sich kaum erklären, wenn man es nicht selbst erlebt hat. Man kann leicht unterschätzen, was einen GPU-beschleunigten Editor unterscheidet, aber wenn man ihn selbst benutzt, ist man zwangsläufig begeistert. Der einzige Grund, warum ich nicht vollständig zu Zed wechsle, ist die fehlende DevContainer-Unterstützung. Ich habe meine devcontainer-Konfiguration mit sehr viel Aufwand eingerichtet, und sie aufzugeben, um alle Tools, Bibliotheken und Einstellungen lokal neu zu installieren, wäre ein großer Rückschritt. Viele warten auf diese Funktion, daher hoffe ich, dass sie irgendwann kommt relevantes Issue
  • Könntest du mehr über deinen benutzerdefinierten DevContainer erzählen?
  • Ich würde gern verstehen, worin der Nutzen von DevContainern besteht. Ich würde meine Umgebung zwar detailliert dokumentieren, aber welche weiteren Vorteile gibt es darüber hinaus?
  • ist mit devpods kompatibel
• Es ist wirklich erfrischend, dass der Editor weniger Speicher und CPU verbraucht als der Browser-Tab meiner Web-App, an der ich gearbeitet habe. Bisher bin ich sehr zufrieden
  • Zed startet für LSP auch Node, daher sollte man das auf jeden Fall überprüfen
  • Bei einer Binärgröße von etwa 0,5 GB fühlt es sich allerdings nicht besonders leichtgewichtig an, zumindest nicht im Vergleich zu einem Browser
• Ich wollte Zed als Daily Driver nutzen, aber die TypeScript-Erfahrung war schlechter als erwartet. Der Editor selbst ist schnell, aber LSP-Aktionen wie jump to declaration waren in unserer Codebasis im Vergleich zu VSCode/Cursor deutlich langsamer
  • Ich würde empfehlen zu prüfen, ob typescript-go als LSP unterstützt wird. Es wurde kürzlich in IDEA hinzugefügt, und ich habe es einige Monate verwendet — wirklich fantastisch
  • Ich hatte dieselbe Erfahrung und bin zum selben Schluss gekommen. Zed war beim Editieren schnell, aber die fortgeschrittenen Funktionen waren langsam, wodurch es sich insgesamt letztlich langsamer anfühlte als VSCode
  • Soweit ich weiß, verwenden beide intern tsserver, deshalb verstehe ich nicht, warum es langsamer ist
  • Electron baut NodeJS mit V8 Pointer Compression, was den Speicherverbrauch um bis zu 50 % senkt und die Geschwindigkeit erhöht
• Ganz okay, aber ich bin ohnehin schon zu Linux gewechselt, und dort läuft Zed ebenfalls sehr gut

[Window Title]
Critical

[Main Instruction]
Unsupported GPU

[Content]
Zed uses DirectX for rendering and requires a compatible GPU.

Currently you are using a software emulated GPU (Microsoft Basic Render Driver) which
will result in awful performance.

For troubleshooting see: https://zed.dev/docs/windows
Set ZED_ALLOW_EMULATED_GPU=1 env var to permanently override.

[Skip] [Troubleshoot and Quit]

Leider hatte ich dieses Problem

• Das ist eigentlich kein Zed-Problem, sondern ein Systemproblem. Heutzutage ist es schwer, überhaupt noch eine Umgebung ohne DirectX zu finden — läuft Windows bei dir vielleicht in einer VM?
• Ich frage mich, was ein Texteditor beim Software-Rendering überhaupt tut, damit es zu „furchtbarer Performance“ kommt
• Zed ist wirklich großartig. Es kann alles, was ich brauche. Man findet leicht, was man braucht, und es ist wirklich schnell. Im ACP-Modus kann man aus der IDE sogar ein CLI-Terminal forken. Damit lassen sich extrem smarte CLI-Agenten wie Cerebras oder Qwen code 480b günstig und leistungsstark nutzen
• Ich habe lange gewartet, aber es gibt immer noch nur ein x86_64-Binary. Ich mag mein ARM Surface Pro wirklich sehr, und es wäre großartig, wenn Zed auf dieser Hardware laufen würde. Falls das Zed-Team diesen Kommentar sieht, bitte denkt daran
  • Ich habe den Quellcode selbst gebaut und nutze es unter Windows aarch64. Auf einem Surface Pro mit 16 GB ist der Build zwar ziemlich langsam, aber es läuft problemlos. Ich hoffe ebenfalls auf ein offizielles Binary
  • Aus irgendeinem Grund fühlt sich ein mit msvc gebautes Zed unter Windows im Vergleich zu Linux extrem langsam an. Es wurde sogar schon ein relevantes Issue dazu eröffnet