- Das Team, das Atom entwickelt hatte, verfolgt mit Zed erneut dasselbe Ziel: einen leichtgewichtigen Editor mit IDE-Funktionen – diesmal auf Basis von Rust, GPU-beschleunigter UI, CRDT und Tree-sitter
- 2017 zeigten sich die Grenzen von Atom weniger in den Fähigkeiten des Teams als vielmehr in Electron und JavaScript: zu wenig Kontrolle über Speicher und Rendering; daraus entstand die Einschätzung: „Wir müssen neu anfangen“
- Rust ermöglicht Zed einen sichereren Umgang mit Shared Memory und Multithreading; eine Copy-on-Write-B-Tree- und
Arc-basierte Rope-Struktur macht O(1)-Snapshots für Hintergrundaufgaben möglich - Zed besitzt zentrale Schichten wie GPUI, Tree-sitter-Erweiterungen, das
editor-Crate, Multi-Buffer und SumTree selbst und gewinnt dadurch feingranulare Kontrolle – nimmt dafür aber geringere Entwicklungsgeschwindigkeit und höhere Onboarding-Kosten in Kauf - Das wichtigste Ergebnis für Nutzer ist ein schneller Editor; die Rust- und
cargo-basierte Struktur macht es Open-Source-Beitragenden leichter, Builds und Änderungen auszuprobieren, und erhöht das Vertrauen beim Mergen
Wie Atoms Vision in Zed weiterlebt
- Zeds Ziel ist eine stärker verfeinerte Form der Vision, die Atom ursprünglich verfolgte
- Ein leichtgewichtiges, minimalistisches Tool, das sich wie ein Texteditor anfühlt
- Ein Tool, das bei Bedarf IDE-Funktionen bietet, ohne dass UI und Nutzungserlebnis langsam oder schwerfällig werden
- Ein erweiterbarer und skriptbarer Editor
- Die Erweiterbarkeit von Emacs beeinflusste die frühe Vision, doch gewünscht war ein Zugriff auf reichhaltigere Textrepräsentationen statt bloßer Manipulation auf Zeichenebene
- Tree-sitter ist eine Grundlage, um Text struktureller als nur als Zeichen zu behandeln; Zed ist zwar noch nicht skriptbar, zielt aber in diese Richtung
- Atom begann auf Basis von Webtechnologien; Rust gab es damals noch nicht, und auch einen nativen Editor in C oder C++ zu bauen, wurde als schwierig eingeschätzt
Warum 2017 die Entscheidung fiel, „neu anzufangen“
- Nachdem Atom 2017 Teletype veröffentlicht hatte, wurden Plattformbeschränkungen zunehmend als größerer Engpass empfunden als mangelnde Erfahrung des Teams
- JavaScript-Arrays verhalten sich wie Arrays von Objektzeigern, wodurch beim Iterieren Kosten für Pointer-Chasing entstehen; Speicherlayout und Pausen des Garbage Collectors ließen sich kaum direkt steuern
- Auch beim Versuch, Zeilenlayout schneller zu machen, mussten iframe, Canvas und APIs zur Textmessung indirekt kombiniert werden; selbst scheinbar einfache Aufgaben wie Cursorposition oder Zeilenlayout wurden komplex
- Electron entstand zwar, um Atom zu ermöglichen, bot aber kaum die Kontrolle, die ein Code-Editor benötigt
- Für einfachere Apps ist es nutzbar, hat aber den Nachteil eines großen Speicher-Footprints
- In einem Code-Editor braucht es direktere Kontrolle über Rendering, Eingabe und Textverarbeitung
- Irgendwann 2017 kam die Einschätzung auf, dass Atom nicht das gewünschte Niveau erreichen könne; der Ausgangspunkt war die Idee, den Kern in Rust zu schreiben, Electron aber als Präsentationsschicht beizubehalten
Der Weg zu Rust und GPU-Beschleunigung
- Zeds Technologiewahl war kein von Anfang an feststehender Plan, sondern entstand schrittweise durch das Entfernen von Beschränkungen
- Zunächst wurde geprüft, den Kern in Rust zu schreiben
- Danach wurde Electron aufgegeben und ein eigenes UI-Framework entwickelt
- Pathfinder wurde verwendet, war aber zu langsam; daraufhin lernte und nutzte das Team eigene Shader und Signed Distance Fields
- GPU-Beschleunigung wurde nicht ausgehend vom Schlagwort „GPU-beschleunigter Editor“ gewählt, sondern aus der Einschätzung heraus, dass direkte Nutzung von Hardware, die die Farbe jedes Bildschirmpixels parallel berechnen kann, schneller sein könnte
- Zed entschied sich gegen das Manipulieren von DOM-Knoten und für eine Richtung, bei der das Rendering näher daran kontrolliert wird, wie Pixel auf dem Bildschirm gezeichnet werden
- Als Beispiel für Performance-Verbesserung brauchte
find-all-matcheszuvor etwa 1 Sekunde, während Sublime Text nahe bei 200 ms lag; allein mit High-Level-Code, der interne APIs aufruft, wurde dies im Release-Build auf 4 ms reduziert - Die Kompilierzeiten von Rust bleiben ein Ärgernis, doch die Möglichkeit, auch auf Basis von High-Level-Abstraktionen Performance erwarten zu können, erwies sich für die Entwicklung von Zed als nützlich
Die Grenze zwischen JavaScript und C++ sowie Rusts Multithreading
- Auch Atom nutzte viel C++, doch die Grenze zwischen JavaScript-Anwendungscode und C++-Bibliothekscode verursachte hohe Kosten
- Um Arbeit in einen Hintergrund-Thread zu verschieben, musste das betreffende Subsystem nach C++ verlagert werden
- Für Shared Memory musste eine C++-Schicht gebaut und anschließend wieder eine JavaScript-API entworfen werden
- Gleichzeitig musste es sich JavaScript-typisch anfühlen und bestehende Eigenschaften beibehalten
- Rust ist multithreading-freundlich designt und passt daher besser zu dem, was Zed erreichen will
- Anfangs führte der Versuch, einen veränderbaren Splay Tree mit Parent-Pointern in Rust zu implementieren, zu Konflikten mit dem Borrow Checker – bis hin zu Zweifeln, ob sich ein echtes System damit bauen ließe
- Später wurde ein Copy-on-Write-B-Tree mit
Arcgebaut; diese Struktur passte auf natürliche Weise zu Multithreading - Zeds grundlegende Textspeicherstruktur, die Rope, kann Snapshots an Hintergrund-Threads im Wesentlichen durch Erhöhen des
Arc-Referenzzählers weitergeben
Die Entscheidung, den gesamten Stack selbst zu besitzen
- Zed entschied sich dafür, große Bausteine selbst zu besitzen – vom für Parsing zuständigen Tree-sitter bis zum GPU-beschleunigten UI-Framework GPUI
- Eine selbst kontrollierte Struktur erlaubt es, benötigtes Verhalten selbst festzulegen und zu implementieren
- Als für Spracherweiterungen WASM genutzt werden sollte, konnte die entsprechende Funktion zu Tree-sitter hinzugefügt werden
- Für Texteditoren wichtige Text-Rendering-Ansätze müssen nicht einem externen UI-Framework überlassen werden
- GPUI wurde 2019 gestartet; die damals vorhandenen UI-Frameworks erfüllten Zeds Anforderungen entweder nicht oder wurden vom Team nicht ausreichend verstanden
- Die Methode, Low-Level-Primitiven selbst zu verstehen und darauf ein System aufzubauen, war bei GPUI eher eine Überlebensstrategie
- Die Kosten sind ebenfalls klar
- Selbstbau dauert lange
- Die Entwicklungsgeschwindigkeit sinkt
- Weil kein weithin bekanntes Framework genutzt wird, müssen neue Mitarbeitende eine Codebasis von rund 300.000 Zeilen von Grund auf lernen
- Gleichzeitig sind die Menschen, die diesen Code geschrieben haben, intern verfügbar und können ihn neuen Teammitgliedern erklären; mit der Zeit könnten die Kosten des Eigenbesitzes sinken und die Vorteile sich aufsummieren
- Es gibt inzwischen auch Beispiele wie loungy, bei denen andere Apps auf GPUI gebaut wurden
Wo Perfektion wichtig ist – und wo man schnell weitergehen sollte
- Der Maßstab des Zed-Teams ist, nur das zu bauen, was nötig ist, und es innerhalb dieses Rahmens so gut wie möglich zu machen
- Statt Zeit in Spekulationen über vielleicht künftig benötigte Funktionen zu investieren, werden tatsächlich benötigte Dinge bewusst und sorgfältig implementiert
- Der Anspruch an Vollständigkeit hängt von der Schicht ab, in der sich der Code befindet
- Schichten wie GPUI, von denen die gesamte App abhängt, benötigen hohe Reife
- Datenstrukturen wie SumTree, die in der gesamten Codebasis verwendet werden und performancekritisch sind, werden ebenfalls sorgfältig behandelt
- Punktuelle Performance-Verbesserungen am Rand werden eher so weit umgesetzt, dass sie ihren Zweck erfüllen, statt übermäßig poliert zu werden
- SumTree nutzt Random Testing, um Edge Cases zu prüfen
- Perfektionismus darf Lernen nicht verhindern; wenn eigener Code lange betrieben wurde, inklusive der nötigen Kompromisse, liefert eine spätere Neufassung eine Grundlage, um das Gelernte einfließen zu lassen
Erkenntnisse aus CRDT und Buffer-Struktur
- Atoms ursprünglicher Buffer war ein JavaScript-String-Array, also ein Array von Zeilen
- Zeds Buffer ist ein multithreading-freundlicher, snapshotfähiger Copy-on-Write-B-Tree, der mehrere benötigte Elemente indiziert
- CRDT war nicht von Anfang an eine selbstverständliche Wahl; dem heutigen Ansatz ging eine Forschungsphase mit der Lektüre mehrerer Papers voraus
- Die CRDT-Implementierung wurde zwei- oder dreimal neu geschrieben, der grundsätzliche Ansatz blieb jedoch weitgehend erhalten
- Bei Atom, dem ersten Code-Editor des Teams, wurde ein schnellerer und rauerer „worse is better“-Ansatz verwendet; diese Erfahrung zeigte, wo die tatsächlichen Schmerzpunkte lagen
- Bei einem Neustart würde der Buffer nicht mehr als einfaches Zeilen-Array gebaut; die früheren langsamen Fälle und Edge Cases verlangen nach einem anspruchsvolleren Design
Schichten, in die Zed besonders viel Sorgfalt investierte
- GPUI ist ein Bereich, in dem nach der kompletten Neuentwicklung ein hoher Reifegrad angestrebt wurde
- Das
editor-Crate umfasst mehrere Schichten, die rohen Buffer-Text in Bildschirmzeilen umwandeln- Tab-Erweiterung
- Soft Wrapping
- Einfügen von Block Decorations
- Fold-Verarbeitung
- Diese Transformationsschichten haben eine konsistente Teststrategie mit eigenschaftsbasiertem Random Testing
- Multi-Buffer ist eine Struktur, die Teile verschiedener Buffer zu einem Ganzen verknüpft, und wird ebenfalls als Kernbestandteil behandelt
- 2021 gab es Fälle, in denen mehrere volle Tage damit verbracht wurden, durch Random Testing gefundene Edge Cases zu reduzieren und zu debuggen
- Wenn diese in Rust geschriebenen Schichten fehlerhaft sind, erscheint nicht bloß irgendwo am Rand des Editors ein Stack Trace; das Programm kann durch einen Panic beendet werden, weshalb Korrektheit wichtig ist
- Um Situationen zu reduzieren, in denen Nutzer beim Öffnen großer Dateien keinerlei Feedback erhalten, wurden außerdem stärker streamingfreundliche Eingaben und Ladeverbesserungen diskutiert; entsprechende Optimierungen sollen in die Preview aufgenommen werden
Was für Nutzer und Beitragende am Ende den Unterschied macht
- Endnutzer werden letztlich vor allem darauf achten, ob der Editor schnell ist
- Bei Entwicklertools und Editoren ist die Wahrscheinlichkeit groß, dass Nutzer selbst zur Codebasis beitragen; deshalb beeinflussen Implementierungssprache und Build-System, wie gut Beiträge möglich sind
- Wäre Zed in C++ geschrieben, gäbe es möglicherweise weniger Nutzer, die selbst Änderungen versuchen würden
- Rust und
cargoerleichtern es, das Projekt zu bauen und Änderungen auszuprobieren, und verringern die Notwendigkeit, CMake oder Gyp zu lernen - Die Strenge des Rust-Compilers hilft aus Sicht der Maintainer, bei externen Beiträgen das Vertrauen beim Mergen zu erhöhen
- Zed möchte Frames unter 3 ms halten; wegen dieser Performance-Anforderung wurde ein GPU-beschleunigtes UI-Framework statt CPU-Rasterisierung gewählt
- Auch an Zig besteht Interesse, doch eine einsprachige Struktur, in der Server und Frontend beide Rust nutzen, hat Vorteile
1 Kommentare
Hacker-News-Kommentare
Zeds Custom-UI-Framework mag im Moment interessant wirken, aber das dürfte sich ändern, sobald man erkennt, dass Barrierefreiheit implementiert werden muss.
Barrierefreiheit in einem Custom-Framework umzusetzen, ohne Performance zu opfern, erfordert plattformspezifisch eine Menge unschöner Arbeit. Zed positioniert sich nicht einfach als Editor, den man notfalls nicht nutzt, sondern als Kollaborationstool; deshalb ist es essenziell, dass alle Entwickler im Team es verwenden können.
Als Screenreader-Nutzer bin ich müde von Rust-basierten „modernen“ Tools, bei denen VoiceOver nur ein leeres Fenster sieht. Eine Custom-UI, die jedes Control jedem Betriebssystem zugänglich machen muss, ist deutlich schwieriger als eine Web-App, bei der man ein paar aria-Labels an Buttons hängt und den Fokus aufräumt.
Zum Glück gibt es inzwischen AccessKit, etwa https://accesskit.dev/, was die Arbeit etwas erleichtern könnte; ich weiß aber nicht, wie gut es für eine große App wie einen Editor geeignet ist.
Da GPUI von Grund auf selbst gebaut wurde, kann man die Barrierefreiheitsfunktionen von Swift- oder webbasierten Apps nicht einfach übernehmen; stattdessen sind sowohl Arbeiten auf Zed-Seite als auch Erweiterungen der GPUI-Funktionen nötig.
Der als Link zur Barrierefreiheitsdiskussion angegebene Verweis https://github.com/zed-industries/zed/pull/1297 führt allerdings zu einem GitHub-Issue über Zurück-/Vorwärts-Buttons und ist daher nutzlos. Vermutlich sollte eigentlich https://github.com/zed-industries/zed/discussions/6576 verlinkt werden.
Zugehörige Dokumentation: https://zed.dev/docs/themes
Barrierefreiheit wurde zwar bedacht, ist aber noch nicht tatsächlich umgesetzt.
Bis vor Kurzem gab es im Wesentlichen nur Bindings für bestehende C-Frameworks oder GUI-Bibliotheken im Proof-of-Concept-Stadium. Das wird künftig besser werden, aber ich verstehe auch die Frustration von Leuten, die auf Barrierefreiheitsfunktionen angewiesen sind.
Allerdings werden viele Projekte wohl zuerst eine solide GUI-Bibliothek bauen wollen und erst danach Barrierefreiheitsfunktionen hinzufügen.
Viele Startups sind gescheitert, weil sie Ressourcen in glänzende Funktionen gesteckt haben, die gar kein Differenzierungsmerkmal waren.
Erfolgreiche Produkte mit nicht-nativer UI nutzen meist Webtechnologien oder ausgereifte Frameworks wie Qt – oder sie sind Ausnahmen wie das 30 Jahre alte Blender. Auch Apple hat mit iTunes Ähnliches gemacht, aber iTunes für Windows war unangenehm; die Leute haben iTunes trotzdem benutzt.
Ich verstehe den Reiz, ein Framework wie GPUI bauen zu wollen, aber der Artikel erklärt nicht, welchen Bezug das zu dem Problem hat, das Zed lösen will.
Also Tools, die nur anhand der Pixel den Inhalt wie ein Mensch verstehen und Text per OCR parsen.
Ich verstehe Technologien wie VoiceOver so, dass sie die tatsächliche Fensterdefinition und Elemente auf Programmebene kennen und nutzen.
Für Projekte, die wegen der GPU-Rendering-Geschwindigkeit für VoiceOver wie ein „leeres Fenster“ aussehen, könnte so ein Ansatz zumindest eine minimale Alternative sein.
Dann frage ich mich auch, ob das bedeutet, dass sämtliche per GPU gerenderten Inhalte, etwa in Spielen, unzugänglich sind.
Auf dem iPhone habe ich mir einen Apple-Kurzbefehl namens „GPT Explains“ erstellt: Per Doppeltipp auf die Rückseite des Smartphones wird ein Screenshot gemacht, an OpenAI geschickt, und ich bekomme eine Beschreibung des Sichtbaren, eine englische Übersetzung nicht-englischer Texte, Gegenargumente zu Behauptungen in Memes usw. zurück.
Eine Kopie ohne API-Key ist hier: https://www.icloud.com/shortcuts/0d063c6810d74a35a017e5a5f69...
Bevor man auf den Hype um einen neuen Texteditor aufspringt, hier der Hinweis, einmal auf die Lizenz zu schauen, der Nutzer zustimmen müssen.
„Customer Data, die aus User Content besteht, der während der Nutzung der Solution erstellt wurde, wird als User Content eingestuft. User Content wird nur dann aus der Nutzerumgebung übertragen, wenn man im Editor das Teilen eines Projekts auswählt, um mit anderen Zed-Nutzern zusammenzuarbeiten.“
„[…] Zeds Zugriff auf diesen User Content ist auf Debugging und die Verbesserung der Solution beschränkt.“
Ich kommentiere das nicht weiter; jeder kann seine eigenen Schlüsse daraus ziehen.
Wenn ich mich entscheide, ein Projekt zur Zusammenarbeit mit anderen zu teilen, ist es doch selbstverständlich, dass der Inhalt dieses Projekts von meinem Rechner übertragen wird. Wie sollte es sonst funktionieren?
Wegen dieses Artikels habe ich Zed ausprobiert, und es wirkte ziemlich vielversprechend. Aber ohne Unterstützung für Remote-Hosts/devcontainer kann ich es nicht nutzen.
Diese Funktion von VSCode ist zentral für meinen Workflow. Ich will eigentlich nicht auf dem Mac entwickeln, sondern den Mac eher als Portal zu den VMs und Containern verwenden, in denen ich code.
Das hilft enorm dabei, Projekte voneinander zu trennen, und ist auch sicherheitstechnisch besser, weil auf der eigentlichen Host-Maschine keine Entwicklungsumgebung oder Abhängigkeiten liegen.
Mich würde interessieren, welchen Vorteil VSCode mit Remote-Host/devcontainer gegenüber einer normalen Remote-Session bietet.
Sehr empfehlenswert: ein hervorragendes Interview, das einen guten Einblick darin gibt, wie Entwickler Entwicklung aus verschiedenen Blickwinkeln betrachten.
Allerdings habe ich einen Einwand.
Nicht „der perfekte Name für einen in Zig gebauten Texteditor ist schon von Zed belegt“, sondern der Name ist „Zag“ ;)
zedsteckted.edist ein Vorgänger vonex,viundedlinund ein bis heute existierender Unix-Zeileneditor.https://en.wikipedia.org/wiki/Ed_(text_editor)
ag, also the silver searcher, ist zwar ebenfalls großartig, aber Zed sehe ich eher beim Code-Editieren als bei der Code-Suche.https://geoff.greer.fm/ag/
Ich nutze Zed nicht, habe aber gesehen, wie José Valim es beim Live-Coding verwendet. Ich nutze hauptsächlich VSCode, aber eine Funktion, die ich in Zed gesehen habe, war ziemlich reizvoll.
Bei „Find All“ erscheinen, wie in VSCode, Ausschnitte aller passenden Dateien im Ergebnis-Panel; dort konnte man die Suchergebnis-Ausschnitte direkt bearbeiten und normale Editierfunktionen wie Multi-Cursor unverändert verwenden.
In VSCode muss man auf ein Suchergebnis klicken, die Datei öffnen und dort ändern, daher fand ich das ziemlich cool und beeindruckend. Nicht genug, um zu wechseln, aber jedes Mal, wenn mich VSCode nervt, fällt es mir wieder ein.
occurundmulti-occur, womit genau so etwas möglich ist. Wirklich hervorragend.In jüngerer Zeit bieten auch Interfaces für Tools wie ripgrep einen editierbaren Modus, was fürs Refactoring sehr praktisch ist. Natürlich lassen sich auch Dateinamen in einem Rutsch bearbeiten.
https://www.masteringemacs.org/article/searching-buffers-occ...
https://rgel.readthedocs.io/en/latest/
https://www.gnu.org/software/emacs/manual/html_node/emacs/Wd...
Es mag absurd klingen, aber einer der Hauptgründe, warum ich JetBrains statt VSCode nutze, ist, dass ich Verzeichnisse durchsuchen und im Navigations-Panel öffnen kann.
Erst durch diesen Kommentar ist mir wieder eingefallen, dass es das gibt; ich sollte es wieder ausprobieren.
https://marketplace.visualstudio.com/items?itemName=jakearl....
Einer meiner Lieblingstricks ist, mit Multi-Cursor zu bearbeiten und Tastenkürzel für Zeilenende oder zum nächsten Wort zu nutzen, um Massenänderungen vorzunehmen.
Schön wäre, wenn das über mehrere Dateien hinweg ginge.
Unter Windows oder Linux läuft es nicht. Sagt bitte wieder Bescheid, wenn es unterstützt wird.
Hervorragendes Interview.
Mir gefiel, wie gründlich darüber nachgedacht wurde, was man übermäßig ausfeilen sollte. Meine beste Arbeit ist, glaube ich, meist erst in der zweiten, dritten oder vierten Runde entstanden.
Mich interessiert, welche Pläne es für skriptbare Konfiguration gibt. Ich habe Zed noch nicht viel genutzt – ist das heute schon möglich? Könnte etwas wie Neon helfen, die Lücke zwischen VSCode- und alten Atom-Nutzern zu schließen?
https://github.com/neon-bindings/neon
— Brooks, Mythical Man-Month
Eine v2 zu beobachten, ist immer spannend. Ich habe gesehen, wie sie durch Funktionsüberladung zur Katastrophe wurde, und auch, wie sie schlanker und schneller wurde und dadurch großartig.
Im heutigen Bereich der Web-Apps gibt es so viele Tools, dass ich mich frage, ob diese Gefahr nicht nur für v2, sondern genauso für v1 gilt. Ich habe in letzter Zeit viele v1-Versionen gesehen, die erstaunlich aufgebläht waren, und oft muss man gezielt nach Tools suchen, die weniger tun.
Ich habe Zed ausprobiert, und es fühlte sich ähnlich wie VSCode an. Ich weiß, dass es Multiplayer-Funktionen gibt, die besser als Live Share sind, aber auf den ersten Blick brauchte es für mich mehr Überzeugungskraft, um zu wechseln
Wenn Zed Xcode ersetzen könnte, würde ich es wohl noch weiter ausprobieren. Von der Löschung der Derived Data oder dem Aufräumen des Build-Ordners bis hin zu zufälligen Crashes: Xcode zu benutzen ist schmerzhaft
Verglichen mit der Developer Experience von Android Studio ist es etwas völlig anderes. Für iOS-Entwicklung habe ich mir immer eine Erfahrung wie mit Android Studio gewünscht
Ich mag native Apps wirklich sehr, aber im Moment hänge ich an VS Code fest. Wenn ich sehe, dass schon das Blinken des Cursors in VS Code viel Strom verbraucht, tut das weh
Ich habe Zed kurz ausprobiert, konnte es aber nicht an meinen Workflow anpassen. Dass es leichtgewichtig und schnell ist, gefiel mir. Die VS-Code-Prozesse liegen bei etwa 3 GB, Zed dagegen bei 300 MB; ein Zehntel des Speichers ist ein relevanter Unterschied
Allerdings brauche ich unbedingt die Jupyter-Notebook-Unterstützung, die VS Code bietet, und ich bin zu sehr daran gewöhnt, vom Mac aus remote auf einer Ubuntu-Maschine zu entwickeln. VS Code macht das sehr gut
Ich hoffe, Zed hält lange genug durch, um irgendwann meinen Workflow zu unterstützen
Vermutlich haben andere einfach mehr Extensions aktiviert
Nach dem Lindy-Effekt https://en.wikipedia.org/wiki/Lindy_effect dürfte es wohl noch ein weiteres Jahr dauern, bis man etwas sieht
Ich habe mir die About-Seite angesehen, und die Live-Coding-Funktion wirkt nützlich. Die Entwickler dürften auch Spaß daran haben. Es ist ja ein interessantes Projekt, bei dem man Algorithmen schreibt, Performance optimiert und auch GPU-Programmierung machen kann
Aber wer braucht noch einen weiteren Texteditor, der vermutlich nie Feature-Parität mit Vim und einem Terminal-Multiplexer erreichen wird?
VS Code ist relativ plötzlich und erst vor Kurzem aufgetaucht und wird von vielen genutzt; das zeigt, dass es auch nach Vim noch Chancen für neue Editoren gab
Ob Zed genug Momentum bekommt, um die Long-Tail-Nachfrage anderer Entwickler zu bedienen, bleibt abzuwarten, aber es ist durchaus spannend, wenn mehr Produkte um Nutzer konkurrieren
Dann müsste man Vim nicht nachahmen, sondern könnte Neovim und alle Plugins direkt nutzen
Ich finde es immer noch schade, dass JetBrains weiter ein Vim-Emulations-Plugin pflegt, das Vim-Nutzer als miserabel bezeichnen. Wenn die IDE ein Neovim-Frontend nativ implementieren würde, hätte sie den viel stärkeren Vorteil, „Neovim und sein Ökosystem vollständig zu unterstützen“; derzeit bleibt es bei „es gibt ein Vim-ähnliches Plugin“
Man sollte das Tool nutzen, das einem gefällt und mit dem man die Arbeit erledigt. Das schließt Vim ein, aber ich bin es leid, wenn so getan wird, als sei die Nutzung von Vim ein unersetzlicher Segen
Ein besserer Denker zu werden, steigert die Produktivität als Programmierer exponentiell stärker als jedes Tool
Es gibt bereits ziemlich funktionsreiche Editoren, mit denen die Leute zufrieden sind oder an die sie sich zumindest gewöhnt haben. Wo kann sich ein neuer Editor positionieren?
„Multiplayer“ ist cool, aber eher ein Edge Case
Beim Geschäftsmodell bin ich mir auch nicht sicher. Wollen die Leute wirklich Channels, Calls und Chat in ihren Code-Editor integriert haben? Persönlich sträube ich mich dagegen fast instinktiv, aber vielleicht bin das nur ich