- L’équipe qui avait créé Atom reprend dans Zed le même objectif — un éditeur léger mais doté de fonctionnalités de niveau IDE — en le réinventant autour de Rust, d’une UI accélérée par le GPU, des CRDT et de Tree-sitter
- En 2017, les limites d’Atom se sont révélées moins liées aux capacités de l’équipe qu’au manque de contrôle sur la mémoire et le rendu dans Electron et JavaScript, ce qui a conduit à la conclusion qu’« il fallait recommencer »
- Rust permet à Zed de gérer plus sûrement la mémoire partagée et le multithreading, et une structure rope basée sur un B-tree copy-on-write et
Arcrend possibles des snapshots en O(1) pour les tâches en arrière-plan - Zed choisit de posséder directement des couches essentielles comme GPUI, les extensions Tree-sitter, la crate
editor, le multi-buffer et SumTree, gagnant ainsi un contrôle fin au prix d’un développement plus lent et d’un coût d’onboarding plus élevé - Pour l’utilisateur, le résultat le plus important est un éditeur rapide, et l’architecture basée sur Rust et
cargofacilite pour les contributeurs open source la compilation et les essais de modifications tout en renforçant la fiabilité des merges
Comment la vision d’Atom s’est prolongée dans Zed
- L’objectif de Zed se rapproche d’une forme plus aboutie de la vision qu’Atom poursuivait à l’origine
- un outil léger, minimaliste, qui donne la sensation d’un éditeur de texte
- un outil capable de fournir des fonctions de niveau IDE quand nécessaire, sans rendre l’interface ni l’expérience utilisateur lentes ou lourdes
- un éditeur extensible et scriptable
- L’extensibilité d’Emacs a influencé la vision initiale, mais l’ambition était d’aller vers un modèle de texte plus riche qu’une simple manipulation caractère par caractère
- Tree-sitter fournit la base permettant de traiter le texte de manière structurelle plutôt qu’au niveau des caractères, et même si Zed n’est pas encore scriptable, c’est bien la direction visée
- Atom est né sur des technologies web ; Rust n’existait pas encore à l’époque, et construire un éditeur natif en C ou C++ était alors jugé difficile
Pourquoi la décision de « recommencer » a été prise en 2017
- Après la sortie de Teletype en 2017, Atom a commencé à donner le sentiment que les contraintes de la plateforme constituaient un goulet d’étranglement plus important que l’inexpérience de l’équipe
- Les tableaux JavaScript se comportaient comme des tableaux de pointeurs vers des objets, ce qui entraînait un coût de déréférencement lors des parcours, sans réel contrôle direct sur l’organisation mémoire ni sur les pauses du garbage collector
- Même pour générer rapidement la mise en page des lignes, il fallait combiner de façon détournée iframes, Canvas et API de mesure de texte, rendant complexes des opérations pourtant simples en apparence comme le positionnement du curseur ou l’agencement des lignes
- Electron est né pour permettre de créer Atom, mais il restait difficile d’y obtenir le niveau de contrôle nécessaire à un éditeur de code
- il peut convenir à des applications plus simples, mais avec l’inconvénient d’une empreinte mémoire importante
- pour un éditeur de code, un contrôle plus direct est nécessaire sur le rendu, la saisie et le traitement du texte
- À un moment en 2017, l’équipe a conclu qu’Atom ne permettrait pas d’atteindre le niveau souhaité, en partant d’abord de l’idée d’écrire le cœur en Rust tout en gardant Electron comme couche de présentation
Le passage à Rust et à l’accélération GPU
- Les choix technologiques de Zed n’ont pas été fixés d’après un plan directeur immuable ; ils se sont définis étape par étape en supprimant progressivement les contraintes
- d’abord, l’équipe a exploré l’idée d’écrire le cœur en Rust
- ensuite, elle a abandonné Electron pour construire son propre framework UI
- elle a utilisé Pathfinder, mais comme cela restait trop lent, elle a appris puis appliqué ses propres shaders et les signed distance fields
- L’accélération GPU n’est pas venue d’un slogan du type « éditeur accéléré par le GPU », mais du constat qu’utiliser directement un matériel capable de calculer en parallèle la couleur de chaque pixel pouvait être plus rapide
- Zed a choisi de contrôler le rendu à un niveau plus proche de la façon de dessiner les pixels à l’écran, plutôt que de manipuler des nœuds DOM
- Exemple d’amélioration des performances :
find-all-matches, qui prenait auparavant environ 1 seconde et où Sublime Text tournait autour de 200 ms, a été ramené à 4 ms dans un build de release avec du code de haut niveau appelant simplement des API internes - Les temps de compilation de Rust restent un sujet d’insatisfaction, mais la possibilité d’obtenir de bonnes performances même au-dessus d’abstractions de haut niveau s’est révélée très utile pour le développement de Zed
La frontière JavaScript/C++ et le multithreading en Rust
- Atom utilisait déjà beaucoup de C++, mais la frontière entre le code applicatif JavaScript et les bibliothèques C++ représentait un coût important
- déplacer un traitement vers un thread d’arrière-plan impliquait de faire descendre les sous-systèmes concernés en C++
- pour utiliser de la mémoire partagée, il fallait créer une couche C++ puis redéfinir une API JavaScript par-dessus
- il fallait aussi préserver une apparence idiomatique côté JavaScript tout en conservant les propriétés existantes
- Rust adopte une conception plus favorable au multithreading, ce qui correspondait mieux à ce que Zed voulait faire
- Au début, l’équipe a essayé d’implémenter en Rust un splay tree mutable avec pointeurs parents, mais s’est heurtée au borrow checker, au point de douter de la faisabilité d’un vrai système
- Elle est ensuite passée à un B-tree copy-on-write avec
Arc, une structure qui s’est naturellement révélée adaptée au multithreading - La rope qui sert de structure de stockage de texte de base dans Zed peut transmettre un snapshot à un thread d’arrière-plan en se limitant essentiellement à incrémenter le compteur de références
Arc
Le choix de posséder toute la stack
- Zed a choisi de posséder directement de gros blocs de sa stack, depuis Tree-sitter pour le parsing jusqu’à GPUI comme framework UI accéléré par le GPU
- Cette approche permet de décider soi-même du comportement nécessaire et de l’implémenter
- lorsqu’il a fallu utiliser WASM dans les extensions de langage, l’équipe a pu ajouter la fonctionnalité directement à Tree-sitter
- elle n’a pas eu à déléguer à un framework UI externe la manière de faire le rendu du texte, un point crucial pour un éditeur de texte
- GPUI a démarré en 2019 ; à l’époque, les frameworks UI existants ne répondaient pas aux besoins de Zed ou n’étaient pas suffisamment compris par l’équipe
- Comprendre directement les primitives sous-jacentes et bâtir le système par-dessus relevait presque d’une stratégie de survie pour GPUI
- Le coût est lui aussi très clair
- construire soi-même prend beaucoup de temps
- cela ralentit le rythme de développement
- comme l’équipe n’utilise pas un framework largement connu, les nouveaux arrivants doivent apprendre à partir de zéro une base de code d’environ 300 000 lignes
- En contrepartie, les auteurs de ce code sont présents en interne pour l’expliquer aux nouveaux membres, et l’équipe estime qu’avec le temps le coût de cette possession directe diminue tandis que les avantages s’accumulent
- Des applications comme loungy ont aussi commencé à être construites sur GPUI
Où viser la perfection et où avancer vite
- Le principe de l’équipe Zed est de ne construire que ce qui est nécessaire, puis de le faire aussi bien que possible dans ce périmètre
- Plutôt que de perdre du temps à anticiper des besoins futurs hypothétiques, elle implémente avec intention et soin ce qui devient réellement nécessaire
- Le niveau d’exigence varie selon la couche où se situe le code
- une couche comme GPUI, dont dépend toute l’application, exige un haut niveau de finition
- une structure de données comme SumTree, utilisée dans toute la base de code et critique pour les performances, est elle aussi traitée avec beaucoup de soin
- des optimisations de performance plus périphériques sont menées jusqu’au niveau suffisant pour atteindre l’objectif, sans polissage excessif
- SumTree utilise des tests aléatoires pour vérifier les edge cases
- Le perfectionnisme ne doit pas bloquer l’apprentissage ; quand on a déjà longtemps exploité un code écrit soi-même, vécu ses compromis, puis qu’on le réécrit, on dispose alors d’une base solide pour intégrer ce qu’on a appris
Leçons tirées des CRDT et de la structure des buffers
- Le buffer initial d’Atom était un tableau de chaînes JavaScript, autrement dit un tableau de lignes
- Le buffer de Zed est un B-tree copy-on-write, compatible avec le multithreading et capable de produire des snapshots, qui indexe aussi plusieurs éléments nécessaires
- Le CRDT n’a pas été un choix évident dès le départ ; l’approche actuelle est issue d’une phase de recherche passée à lire plusieurs articles académiques
- L’implémentation du CRDT a été réécrite deux ou trois fois, mais l’approche de fond est restée globalement la même
- Sur Atom, leur premier éditeur de code, l’équipe avait adopté une approche plus rapide et plus brute de type « worse is better », ce qui lui a permis d’identifier où se situaient réellement les points de douleur
- Si elle devait repartir de zéro, elle ne construirait plus le buffer comme un simple tableau de lignes ; les lenteurs et edge cases du passé imposent une conception plus robuste
Les couches particulièrement soignées dans Zed
- GPUI est une zone où l’équipe a visé un haut niveau de finition, puisqu’elle a réécrit l’ensemble
- La crate
editorinclut plusieurs couches qui convertissent le texte brut du buffer en lignes affichables à l’écran- expansion des tabulations
- retour à la ligne automatique
- insertion de décorations par blocs
- gestion du pliage de code
- Ces couches de transformation partagent une stratégie de test cohérente fondée sur des tests aléatoires basés sur des propriétés
- Le multi-buffer, qui assemble en une seule vue des portions de buffers différents, est également traité comme un élément central
- En 2021, l’équipe a déjà passé plusieurs journées entières à réduire puis déboguer des edge cases détectés par des tests aléatoires
- Comme cette couche est écrite en Rust, une erreur peut provoquer non pas une simple stack trace dans un coin de l’éditeur, mais un panic du programme tout entier ; la correction y est donc essentielle
- Des discussions ont aussi porté sur des entrées et un chargement plus orientés streaming afin de réduire les situations où l’utilisateur n’obtient aucun retour en ouvrant de gros fichiers, et des optimisations liées doivent arriver en preview
Ce que cela change pour les utilisateurs et les contributeurs
- Pour l’utilisateur final, le critère principal reste au bout du compte la rapidité de l’éditeur
- Dans les outils de développement et les éditeurs, les utilisateurs ont plus de chances de contribuer eux-mêmes au codebase ; le langage d’implémentation et le mode de build influencent donc cette possibilité
- Si Zed avait été écrit en C++, il y aurait peut-être eu moins d’utilisateurs prêts à le modifier directement
- Rust et
cargofacilitent la compilation du projet et les essais de modifications, tout en évitant d’avoir à apprendre CMake ou Gyp - La rigueur du compilateur Rust contribue aussi à augmenter la fiabilité des merges lorsque le projet reçoit des contributions externes
- Zed cherche à maintenir ses frames sous les 3 ms, et cette exigence de performance l’a conduit à choisir un framework UI accéléré par le GPU plutôt qu’une rasterisation CPU
- L’équipe s’intéresse aussi à Zig, mais voit des avantages à une stack monolangage où le serveur comme le frontend sont tous deux en Rust
1 commentaires
Avis de Hacker News
Le framework d’UI personnalisé de Zed peut sembler intéressant pour l’instant, mais les choses risquent de changer dès qu’ils se rendront compte qu’il faut implémenter l’accessibilité.
Implémenter l’accessibilité dans un framework personnalisé sans sacrifier les performances demande beaucoup de travail sale spécifique à chaque plateforme. Zed ne se positionne pas comme un simple éditeur qu’on peut choisir de ne pas utiliser, mais comme un outil de collaboration ; il est donc indispensable que tous les développeurs d’une équipe puissent s’en servir.
En tant qu’utilisateur de lecteur d’écran, je suis lassé de ces outils « modernes » basés sur Rust où VoiceOver ne voit qu’une fenêtre vide. Une UI personnalisée, qui doit exposer tous les contrôles à tous les OS, est bien plus difficile qu’une application web où il suffit d’ajouter quelques labels aria aux boutons et de remettre le focus en ordre.
Heureusement, des projets comme AccessKit, https://accesskit.dev/, peuvent rendre le travail un peu plus simple, mais je ne sais pas dans quelle mesure ils conviennent à une grosse application comme un éditeur.
Comme ils ont créé GPUI à partir de zéro, ils ne peuvent pas réutiliser telles quelles les fonctionnalités d’accessibilité dont disposent les applications Swift ou web ; cela nécessitera à la fois du travail côté Zed et l’extension des fonctionnalités de GPUI.
Cela dit, le lien indiqué pour la discussion sur l’accessibilité, https://github.com/zed-industries/zed/pull/1297, pointe vers une issue GitHub concernant les boutons précédent/suivant, donc il n’est pas utile. Ils voulaient probablement lier https://github.com/zed-industries/zed/discussions/6576.
Documentation liée : https://zed.dev/docs/themes
Ils ont bien pensé à l’accessibilité, mais ce n’est pas encore réellement implémenté.
Il y a encore peu, on n’avait guère que des bindings vers des frameworks C existants ou des bibliothèques GUI au stade de preuve de concept. Cela va s’améliorer, mais je comprends aussi la frustration de ceux qui dépendent des fonctionnalités d’accessibilité.
Cela dit, beaucoup de projets chercheront probablement d’abord à construire une bibliothèque GUI solide, puis à ajouter les fonctionnalités d’accessibilité ensuite.
Beaucoup de startups ont échoué en consacrant leurs ressources à des fonctionnalités clinquantes qui ne constituaient même pas un facteur de différenciation.
Les produits qui ont réussi avec une UI non native utilisent en général des technologies web ou des frameworks matures comme Qt, ou bien sont des exceptions comme Blender, vieux de 30 ans. Apple a fait quelque chose de similaire avec iTunes, mais iTunes pour Windows était désagréable ; les gens utilisaient quand même iTunes, tout simplement.
Je comprends l’attrait de créer un framework comme GPUI, mais l’article n’explique pas en quoi cela est lié au problème que Zed cherche à résoudre.
Des outils qui regarderaient simplement les pixels, les comprendraient comme un humain, et utiliseraient l’OCR pour analyser le texte.
D’après ce que je comprends, des technologies comme VoiceOver connaissent et exploitent la définition réelle de la fenêtre et de ses éléments au niveau programmatique.
Pour des projets qui veulent la vitesse du rendu GPU et qui apparaissent donc comme une « fenêtre vide » à VoiceOver, ce type d’approche pourrait peut-être constituer au moins une alternative minimale.
Dans ce cas, je me demande aussi si cela signifie que tout contenu rendu par GPU, comme dans les jeux, est inaccessible.
Sur iPhone, j’ai créé un raccourci Apple appelé « GPT Explains » : un double tap au dos du téléphone prend une capture d’écran, l’envoie à OpenAI, puis renvoie une description de ce qui est visible, une traduction en anglais du texte non anglais, des contre-arguments aux affirmations d’un mème, etc.
Une copie sans la clé d’API est ici : https://www.icloud.com/shortcuts/0d063c6810d74a35a017e5a5f69...
Avant de suivre la nouvelle mode des éditeurs de texte, je laisse ceci pour dire qu’il vaut mieux jeter un œil à la licence que l’utilisateur doit accepter.
« Les Customer Data constituées du contenu utilisateur généré lors de l’utilisation de la Solution sont classées comme User Content. Le User Content n’est transmis hors de l’environnement de l’utilisateur que lorsque celui-ci choisit de partager un projet dans l’Editor afin de collaborer avec d’autres utilisateurs de Zed. »
« [...] l’accès de Zed à ce User Content est limité au débogage et à l’amélioration de la Solution. »
Je n’ajouterai pas d’interprétation ; chacun peut en tirer ses propres conclusions.
Si l’on choisit de partager un projet avec quelqu’un d’autre pour collaborer, il est évident que le contenu du projet est transmis hors de sa machine. Sinon, comment cela fonctionnerait-il ?
Cet article m’a donné envie d’essayer Zed, et ça m’a semblé assez prometteur. Mais comme il ne prend pas en charge les hôtes distants/devcontainer, je ne peux pas l’utiliser
Cette fonctionnalité de VSCode est au cœur de mon flux de travail. En pratique, je n’ai pas envie de développer sur Mac ; je veux utiliser le Mac comme un portail vers les VM et conteneurs dans lesquels je code
Ça aide énormément à isoler les projets, et c’est aussi meilleur côté sécurité, puisqu’on ne garde pas d’environnement de développement ni de dépendances sur la machine hôte réelle
Je me demande quels avantages les hôtes distants/devcontainer de VSCode apportent par rapport à une session distante classique
Excellente interview, vivement recommandée : elle donne un très bon aperçu de la façon dont les développeurs envisagent le développement sous plusieurs angles
J’ai toutefois un point de désaccord
Ce n’est pas que « le nom parfait pour un éditeur de texte écrit en Zig est déjà pris par Zed » : ce nom, c’est « Zag » ;)
zedcontiented.edest le prédécesseur deex,vietedlin, et reste un éditeur en ligne de la famille Unix encore présent aujourd’huihttps://en.wikipedia.org/wiki/Ed_(text_editor)
À l’inverse,
ag, c’est-à-dire the silver searcher, est très bien aussi, mais je vois Zed comme plus proche de l’édition de code que de la recherche de codehttps://geoff.greer.fm/ag/
Je n’utilise pas Zed, mais j’ai vu José Valim s’en servir en live coding. J’utilise surtout VSCode, et une fonctionnalité que j’ai vue dans Zed m’a paru assez séduisante
Quand on fait “Find All”, des extraits de tous les fichiers correspondants apparaissent dans le panneau de résultats, comme dans VSCode, mais on pouvait modifier directement les extraits des résultats de recherche, tout en utilisant les fonctions d’édition habituelles comme les curseurs multiples
Dans VSCode, il faut cliquer sur un résultat de recherche pour ouvrir le fichier puis le modifier là-bas, donc j’ai trouvé ça très chouette et impressionnant. Pas au point de basculer, mais j’y repense parfois chaque fois que VSCode m’agace
occuretmulti-occurdepuis les années 80, et permet ce genre de chose. C’est vraiment excellentPlus récemment, les interfaces vers des outils comme ripgrep proposent aussi un mode éditable, très pratique pour le refactoring. Et bien sûr, on peut aussi modifier les noms de fichiers en masse
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...
Ça peut paraître absurde, mais l’une des principales raisons pour lesquelles j’utilise JetBrains plutôt que VSCode, c’est qu’on peut faire une recherche dans un répertoire et l’ouvrir dans le panneau de navigation
C’est seulement en voyant ce commentaire que je me suis rappelé son existence ; il va falloir que je réessaie
https://marketplace.visualstudio.com/items?itemName=jakearl....
Une de mes astuces préférées consiste à éditer avec des curseurs multiples puis à utiliser les raccourcis pour aller en fin de ligne ou au mot suivant afin de faire des modifications en masse
Ce serait bien de pouvoir faire ça sur plusieurs fichiers
Ça ne fonctionne pas sous Windows ni Linux. J’aimerais qu’on me prévienne quand ce sera pris en charge
Excellente interview
J’ai aimé la réflexion approfondie sur ce qu’il faut peaufiner à l’excès. Mes meilleurs travaux sont généralement arrivés, il me semble, autour du deuxième, troisième ou quatrième passage
Je me demande quels sont les plans pour permettre de gérer la configuration par script. Je n’ai pas encore beaucoup utilisé Zed ; est-ce déjà possible aujourd’hui ? Est-ce que quelque chose comme Neon pourrait aider à combler l’écart entre VSCode et les anciens utilisateurs d’Atom ?
https://github.com/neon-bindings/neon
— Brooks, Mythical Man-Month
Voir une v2 est toujours intéressant. J’en ai vu devenir des catastrophes à cause d’une surcharge de fonctionnalités, et d’autres devenir excellentes parce qu’elles étaient plus simples et plus agiles
Dans le domaine des web apps aujourd’hui, il y a tellement d’outils que je me demande si ce risque ne s’applique pas autant à la v1 qu’à la v2. Je vois souvent des v1 étonnamment boursouflées, et il faut souvent chercher délibérément des outils qui en font moins
J’ai essayé Zed et il m’a semblé assez proche de VSCode. Je sais qu’il dispose de fonctionnalités multijoueurs meilleures que Live Share, mais vu de l’extérieur, il m’aurait fallu davantage d’arguments pour me convaincre de basculer
Si Zed pouvait remplacer Xcode, j’aurais sans doute envie de l’utiliser davantage. Entre la suppression des derived data, le nettoyage du build folder et les plantages aléatoires, utiliser Xcode est douloureux
Comparé à l’expérience développeur d’Android Studio, c’est le jour et la nuit. J’ai toujours voulu retrouver une expérience à la Android Studio dans le développement iOS
J’aime vraiment les apps natives, mais pour l’instant je suis coincé avec VS Code. Ça fait mal de voir que même le clignotement du curseur dans VS Code consomme beaucoup d’énergie
J’ai essayé Zed brièvement, mais je n’ai pas réussi à l’adapter à mon flux de travail. J’ai apprécié sa légèreté et sa rapidité. Les processus de VS Code tournent autour de 3 Go, alors que Zed est à 300 Mo ; un dixième de la mémoire, c’est une différence significative
Mais j’ai absolument besoin de la prise en charge des Jupyter Notebook offerte par VS Code, et je suis trop habitué au développement à distance depuis un Mac vers une machine Ubuntu. VS Code fait ça très bien
J’espère que Zed tiendra assez longtemps pour finir par prendre en charge mon flux de travail
Peut-être que les autres ont simplement beaucoup plus d’extensions activées
D’après l’effet Lindy https://en.wikipedia.org/wiki/Lindy_effect, il faudra sans doute encore au moins un an avant de voir quelque chose
J’ai regardé la page About, et les fonctionnalités de live coding ont l’air utiles. Les développeurs doivent aussi être enthousiastes : c’est un projet amusant, avec des algorithmes, de l’optimisation des performances et même de la programmation GPU
Mais qui a besoin d’un énième éditeur de texte qui n’atteindra probablement jamais la parité fonctionnelle avec Vim et les multiplexeurs de terminal ?
VS Code est apparu assez récemment, presque d’un coup, et beaucoup de gens l’utilisent ; cela montre qu’il y avait encore de la place pour de nouveaux éditeurs après Vim
Reste à voir si Zed gagnera assez d’élan pour répondre à la longue traîne des besoins d’autres développeurs, mais voir davantage de produits se faire concurrence pour attirer des utilisateurs est plutôt réjouissant
Inutile d’imiter Vim : on pourrait exploiter directement Neovim et tous ses plugins
Je trouve toujours dommage que JetBrains continue de maintenir un plugin qui imite Vim et que les utilisateurs de Vim qualifient de médiocre. Implémenter nativement un front-end Neovim dans l’IDE donnerait un argument bien plus fort — « prise en charge complète de Neovim et de son écosystème » — alors qu’aujourd’hui on en reste à « il y a un plugin qui ressemble à Vim »
Il suffit d’utiliser l’outil qu’on aime et qui permet de faire le travail. Cela inclut Vim, mais j’en ai assez qu’on fasse comme si utiliser Vim était une bénédiction irremplaçable
Devenir meilleur dans sa façon de penser augmente exponentiellement la productivité d’un programmeur, bien plus que n’importe quel outil
Il existe déjà des éditeurs assez riches en fonctionnalités, dont les gens sont satisfaits ou auxquels ils sont au moins habitués. Où un nouvel éditeur peut-il trouver sa place ?
Le « multijoueur » est sympa, mais ça reste plutôt un cas limite
Je ne suis pas non plus convaincu par le modèle économique. Les gens veulent-ils vraiment que les canaux, les appels et le chat soient intégrés à leur éditeur de code ? Personnellement, j’ai presque un rejet instinctif, mais c’est peut-être juste moi