Interview de Mitchell Hashimoto : Ghostty, Zig et la maintenance open source

• Mitchell Hashimoto, après Vagrant, Terraform et Vault, a créé Ghostty et Vouch, et y expose ses critères sur les terminaux, Zig, la maintenance open source et la qualité produit
• Ghostty est né comme projet personnel pour apprendre la programmation GPU, la programmation système desktop/single-node et Zig, avant d’évoluer vers un terminal natif multiplateforme rapide et riche en fonctionnalités
• Pour lui, un terminal ne doit pas chercher à tout absorber comme un navigateur, mais préserver la composabilité des applications textuelles, l’automatisation et un modèle de sécurité clair, même si le flux d’octets non structuré du PTY reste une limite
• Un mainteneur open source n’a pas d’obligation envers les utilisateurs, mais pour produire un bon logiciel, il faut selon lui résoudre plusieurs problèmes via une fonctionnalité cohérente plutôt que d’accepter chaque demande telle quelle
• Les grands changements de Zig pèsent sur l’aval, mais améliorent la qualité des API et des outils de compilation ; il estime aussi que l’IA peut réduire le travail répétitif lié aux gros changements et alléger la charge de compatibilité descendante

---

Pourquoi Ghostty a vu le jour

• Après avoir créé Mitchell Hashimoto, Vagrant, Packer, Consul, Terraform, Vault, Nomad et Waypoint, Mitchell Hashimoto travaille aujourd’hui sur Ghostty et Vouch
• Ghostty est parti d’un constat simple : après environ 15 ans à développer des applications CLI, il ne comprenait toujours pas vraiment comment fonctionnait un émulateur de terminal
• Après avoir quitté Hashicorp, il voulait revenir à trois domaines en particulier
  • la programmation GPU dans un contexte antérieur à l’IA
  • la programmation système desktop/single-node, différente des systèmes distribués
  • l’usage de Zig
• Son objectif initial était d’exécuter vim et un compilateur, de faire en sorte que Ghostty puisse se construire lui-même, puis de l’abandonner
• En explorant davantage l’écosystème des terminaux, il a jugé qu’il manquait un outil rapide, riche en fonctionnalités et natif sur plusieurs plateformes
• Après l’avoir partagé avec des amis sur Discord, des utilisateurs quotidiens sont apparus, et le Discord de Ghostty est en fait né de la transformation d’un salon de discussion entre amis en espace dédié
• Il a longtemps gardé le projet en bêta privée, estimant qu’une visibilité publique pouvait attirer une attention excessive

Jusqu’où un terminal doit-il s’étendre ?

• Hashimoto est opposé à l’idée de pousser le terminal sans limite vers une gigantesque plateforme applicative
• Un terminal pourrait, comme un navigateur ou l’ancien runtime Java, intégrer la vidéo, l’accès au micro ou même des layouts réactifs, mais il estime que navigateur, desktop et applications textuelles à grille monospace ont chacun leur propre rôle
• Les applications textuelles sont rapides à implémenter, faciles à manipuler, et doivent conserver un modèle de sécurité clair
• La grande force des applications en terminal réside dans leur composabilité
  • les TUI en ont moins la nature, mais la plupart des outils CLI disposent de mécanismes qui permettent d’aller au-delà de stdin/stdout et de les utiliser comme des fonctions
  • la philosophie UNIX du « faire une seule chose, mais bien » en est l’expression extrême
  • Neovim et les outils IA exposent de plus en plus de flags en ligne de commande
• De meilleures applications de terminal mènent à une meilleure automatisation et à une meilleure scriptabilité
• Le grand problème reste celui des signaux in-band du PTY, c’est-à-dire un flux d’octets non structuré incluant des séquences d’échappement
• L’écosystème Nushell tente d’y remédier à un niveau séparé, mais Hashimoto estime qu’une amélioration plus fondamentale est nécessaire
• Même parmi ceux qui n’aiment pas l’écosystème Microsoft, il considère que PowerShell fait beaucoup de choses correctement du point de vue des données structurées

Imaginer une API de terminal non legacy

• Lorsqu’il réfléchit à une nouvelle API de terminal, Hashimoto regarde du côté des frameworks des grandes plateformes applicatives comme les navigateurs, Emacs, Apple, Microsoft, Android ou les consoles de jeu
• Il estime qu’il faut d’abord étudier les précédents déjà accumulés, comme le DOM et les API JS du web, AppKit, Cocoa et SwiftUI chez Apple, Win32 et WinUI sur Windows, ou GTK et Qt sur Linux
• Rien que pour l’accès au presse-papiers, les protocoles historiques de terminal sont centrés sur le texte, alors que les desktops gèrent depuis longtemps les images et divers types MIME ; il faut donc consulter la documentation du presse-papiers propre à chaque plateforme
• Il n’a pas encore introduit de protocole personnalisé dans Ghostty

• API n-screen

  • Les terminaux actuels disposent généralement de deux écrans : le main screen et l’alt screen
  • Le main screen est plus proche du shell et du scrollback, tandis que l’alternate screen correspond davantage à Neovim et à la plupart des TUI
  • Cette structure consiste à activer ou désactiver l’un de ces deux modes, en occupant généralement tout l’écran et en perdant le scrollback
  • Hashimoto imagine une API n-screen permettant de créer et remplir en arrière-plan un nombre illimité d’écrans
  • Chaque écran pourrait avoir une taille de grille différente et être superposé, tandis que l’émulateur de terminal gérerait les retours à la ligne, la sélection et le routage des événements souris
  • Si un écran donné est désigné comme fenêtre indépendante, l’émulateur pourrait aussi rendre en dehors de la grille
  • Il cite par exemple la possibilité d’ouvrir simultanément des onglets Neovim comme de vrais onglets de fenêtre natifs

• Protocole de boutons

  • Les protocoles souris actuels ne reçoivent des événements que lorsque l’utilisateur clique une cellule de la grille de l’écran courant
  • Les entrées historiques passées dans le scrollback ne peuvent pas recevoir d’événements de clic
  • Les terminaux prennent déjà en charge le protocole d’hyperliens OSC 8
  • Hashimoto imagine un protocole de boutons similaire à OSC 8, qui enverrait au programme un message défini lorsqu’un clic a lieu
  • Par exemple, un bouton avec l’identifiant open_profile pourrait rester enregistré même si l’utilisateur remonte dans l’historique
  • Cette fonctionnalité concernerait les applications du main screen avec scrollback, et rejoint le problème d’applications comme Claude Code, où l’ouverture de fichiers ou les liens internes cessent de fonctionner une fois entrés dans l’historique

Absence de standard et maintenance open source

• Hashimoto a expérimenté le remplacement complet du protocole PTY par Wayland, avant d’abandonner l’idée
• Il voit le terminal comme une sorte de serveur de fenêtrage gérant des fenêtres et des widgets, et considère Wayland comme un bon protocole pour les problèmes de desktop local et de rendu de fenêtres
• L’un des problèmes du terminal est qu’il n’existe plus d’organisme de standardisation
• D’anciennes spécifications subsistent, mais depuis vingt ans, la standardisation s’est surtout faite en fonction de ce que fait le terminal le plus populaire du moment
• Résultat : de nombreuses fonctionnalités se sont entremêlées, sans acteur portant une vision forte et assumée
• Il n’a pas encore décidé du chemin à suivre, et envisage aussi la création d’un nouvel espace applicatif textuel non terminal, avec une couche de traduction terminal pour les applications legacy

• L’équilibre entre demandes utilisateur et grande vision

  • Hashimoto affirme publiquement depuis longtemps qu’un mainteneur open source a zéro obligation envers ses utilisateurs
  • La première ligne des licences open source dit « as is, no warranty », et son point de vue est que l’utilisateur reçoit un logiciel gratuit sans pour autant acquérir un droit à exiger quoi que ce soit
  • En même temps, il dit ressentir une responsabilité à corriger les problèmes et améliorer le logiciel, parce qu’il veut construire un bon produit
  • Certains jours, il consulte les issues et corrige les problèmes d’autres personnes ; d’autres jours, il ignore issues, discussions et PR pour se concentrer sur ce qu’il veut faire
  • S’il ne traite que les issues utilisateur chaque jour, le logiciel devient stable mais figé ; s’il accepte toutes les PR, il évolue mais perd sa vision
  • Selon lui, la plupart des contributions ne règlent qu’un problème individuel précis, et tout accepter finit par empiler le code comme une montagne
  • À l’inverse, quand on comprend en profondeur le problème, on peut résoudre simultanément plusieurs demandes via un système unique et élégant
  • Dans une vidéo sur la conception de fonctionnalités, il montre un cas où 3 ou 4 demandes distinctes ont été fermées car une autre fonctionnalité les résolvait toutes en même temps

• Distinguer richesse fonctionnelle et bloat

  • La recherche, l’une des fonctionnalités les plus demandées dans Ghostty, a été implémentée puis livrée
  • Certains utilisateurs ont critiqué cette fonction, estimant qu’elle rompait avec le minimalisme de Ghostty et ajoutait du bloat, mais Hashimoto répond qu’il présente Ghostty comme un terminal riche en fonctionnalités
  • Il distingue clairement richesse fonctionnelle et bloat
  • La recherche consomme de l’espace disque et un chargement en RAM, mais a été conçue pour n’exécuter aucun code tant qu’elle n’est pas utilisée
  • Il considère donc qu’il s’agit d’une fonctionnalité sans coût d’exécution pour les utilisateurs qui ne s’en servent pas
  • Ghostty vise à être un terminal que l’on peut adapter à ses besoins, qui fonctionne bien par défaut et qui masque ses fonctionnalités jusqu’au moment où l’on en a besoin ou où on les recherche
  • À la demande de maintenir des flags de suppression de fonctionnalités, il répond que demander au mainteneur de gérer ces flags revient au même type d’exigence que demander à l’utilisateur de maintenir un fork sans cette fonctionnalité

Les droits dans l’open source, les changements de Zig et la qualité des API

• Hashimoto estime qu’il devrait exister bien davantage de forks personnels et de forks maintenus
• Selon lui, l’open source financé par le capital-risque a fait émerger une génération qui attend des projets très polis, avec site web, support payant, support Slack ou Discord et une expérience quasi produit
• Pourtant, le cœur de l’open source n’est pas la garantie produit, mais la liberté et les droits
  • utiliser comme on veut
  • modifier
  • forker
• La stabilité ni l’obligation de maintenance ne font partie de ces droits
• Il affirme qu’on ne peut pas faire porter aux seuls mainteneurs la responsabilité d’un commit introduisant une faille de sécurité ; l’utilisateur porte aussi une part de responsabilité s’il n’a pas examiné ce commit
• Si l’on veut des garanties plus fortes et le droit de blâmer quelqu’un, il faut payer le logiciel et entrer dans une relation vendeur-client
• Dans un projet personnel, il peut aussi refuser de merger une PR qui corrige un bug qu’il ne rencontre pas lui-même
  • fusionner une PR, c’est selon lui promettre de maintenir ce code pour toujours

• Son regard sur Zig

  • En choisissant Zig, Hashimoto savait ce qu’il acceptait, et en patchant le compilateur, il a appris à comprendre la communauté, la culture et la philosophie du langage
  • Les changements d’I/O qui n’ont pas encore commencé seront selon lui parmi les travaux les plus difficiles dans Zig
  • Même si Zig gagne en popularité, Andrew ne recule pas devant les changements qu’il juge nécessaires, et Hashimoto dit apprécier cela en tant qu’utilisateur aval
  • Zig 0.15 a modifié l’interface writer, ce qui a touché presque tout le code qui produit de la sortie, mais il juge que l’API y a beaucoup gagné
  • Zig se concentre sur les outils de compilation, allant jusqu’à supprimer certaines fonctionnalités du langage pour accélérer la compilation
  • Il explique que l’ensemble du terminal lib-ghostty peut être compilé instantanément, mais qu’Andrew considère encore ce temps, mesuré en millisecondes, comme trop lent
  • Zig 1.0 arrivera un jour, mais selon lui pas avant encore quelques années
  • L’IA peut réduire la douleur aval causée par les changements de langage
  • En montrant comment effectuer une modification dans différents contextes puis en demandant d’appliquer le reste, environ 90 % d’un gros diff ont pu être automatisés
  • Si l’on peut expliquer comment passer d’un état A à un état B, cela suggère selon lui un futur où la compatibilité descendante a moins de poids
  • C’est ironique au regard de la forte politique anti-IA de Zig, mais il estime malgré tout que l’IA amortit la douleur des changements côté utilisateurs aval

• Bibliothèques et conception d’API

  • La méthode la plus concrète pour apprendre à bien concevoir une bibliothèque est d’utiliser soi-même de nombreuses bibliothèques issues de plusieurs communautés
  • Comme lorsqu’on apprend des langages qu’on n’utilisera peut-être jamais au travail, utiliser des bibliothèques issues d’écosystèmes variés élargit la perspective
  • À l’université, il a créé de petits produits jouets en Prolog, Haskell, Clojure et Java, apprenant au passage les systèmes de build, l’utilisabilité, les bibliothèques, les frameworks web, les serveurs web et les serveurs d’applications propres à chaque écosystème
  • Il estime que la culture de chaque écosystème imprègne la séparation des préoccupations dans les bibliothèques et frameworks, ainsi que la forme des API
  • Il cite comme exemple de transfert de concepts le fait d’avoir essayé en Ruby le builder pattern, très utilisé depuis longtemps en Java, et d’avoir trouvé cela pertinent
  • Pour Docker, beaucoup d’éléments liés au déploiement et au runtime se mélangeaient selon lui au flux de développement ; avec Vagrant, il a donc volontairement choisi des noms, une CLI et une configuration directement centrés sur le développement

• Le dilemme du créateur d’outils et la stack technique

  • Hashimoto dit avoir toujours été un fabricant d’outils et croire au dilemme du créateur d’outils
  • On comprend profondément un problème et on crée l’outil idéal, mais si cet outil devient populaire, on risque de ne plus être un utilisateur réel et de se transformer en créateur d’outils déconnecté du terrain
  • Il utilise le terminal tous les jours, mais ne développe pas suffisamment de TUI, et dépend donc de mainteneurs comme rockorager, qui maintient plusieurs clients e-mail et IRC et rédige aussi des spécifications
  • Concernant la stack technique actuelle, il a une attitude qu’il résume à « ça va »
  • Il voit beaucoup de qualités dans le front-end, TypeScript et la communauté typée autour de React, mais juge que les changements sont trop nombreux, la complexité trop élevée et les couches d’abstraction insuffisamment nettes
  • Il affirme que, comme pour le passage de HTTP/1 à HTTP/2 puis HTTP/3, la complexité a augmenté de manière non linéaire dans de nombreux domaines
  • Selon lui, l’industrie va trop vite, complexifie ce qui aurait pu rester plus simple, et l’IA ainsi que les outils associés accélèrent encore ce mouvement

Principes, culture, qualité et apprentissage

• Il explique que les documents de principes chez Hashicorp comme la manière de développer Ghostty reflétaient tous sa propre personne, ce qui les rendait faciles à mettre en pratique au quotidien
• Si l’on se fixe des principes qui ne correspondent pas à qui l’on est, ils restent selon lui aussi difficiles à appliquer que des résolutions du Nouvel An
• Ghostty accorde autant d’importance à un cœur multiplateforme qu’à une interface graphique native
  • le cœur est multiplateforme
  • la GUI, elle, ne cherche pas à forcer le multiplateforme et préfère les approches natives à chaque plateforme
• Il estime que les projets open source et Internet devraient être une collection de tribus distinctes
• Il n’aime pas l’idée que les langages de programmation deviennent tous des sortes de plus petit dénominateur commun doté de toutes les fonctionnalités possibles ; pour lui, les contraintes créent la créativité et la culture
• Il dit aimer le langage Rust et sa philosophie, mais pas la culture Rust, en précisant que cela ne signifie pas que les membres de la communauté Rust sont de mauvaises personnes
• Zig, selon lui, a des positions nettes et polarisantes sur la technique, la gestion de communauté, le financement, la PR, les billets de blog et même la manière de parler ; il dit respecter cette étrangeté et continue donc à soutenir financièrement le projet et à l’utiliser
• Pour livrer vite sans sacrifier la qualité, il faut comprendre non seulement le problème précis d’un client, mais aussi le contexte qui l’y a mené et les problèmes en amont
• Il dit ne pas savoir comment résoudre cela à l’échelle d’une entreprise, mais dans son cas il juge en tant qu’utilisateur important du logiciel qu’il construit
• L’IA peut être utilisée de manière brute pour une démo ou pour valider une direction, mais le code destiné à la production doit être lu, compris puis publié avec un niveau de qualité réel
• Pour apprendre le C, comprendre comment fonctionne un ordinateur est plus important que le langage lui-même
  • il faut comprendre le scheduling CPU, la mémoire, les hiérarchies de cache, les systèmes de fichiers, les disques et l’accès aux fichiers
  • travailler juste au-dessus de la couche syscall, comme en C, Zig ou Rust, aide à mieux comprendre ce qu’il se passe
  • les API d’ouverture de fichiers en Python, JavaScript ou Ruby abstraient de nombreux détails
  • même les fonctions de bibliothèque standard ne doivent pas être tenues pour acquises : puisqu’elles ont été écrites par quelqu’un, il conseille d’aller les lire soi-même et de creuser leur fonctionnement

[unsure4000]

C’est sorti à peu près au même moment, mais l’ambiance est tellement différente que c’est amusant lol
Mon avis sur la réécriture de Bun en Rust

[sea715]

• La plupart des débats ne portent pas sur les idées, mais sur l’ego
  haha...

[ffdd270]

mdr mdr mdr mdr mdr mdr mdr mdr mdr mdr mdr

[GN⁺]

Réactions sur Lobste.rs

• Excellente interview, et la phrase que j’ai préférée était : « Je ne suis pas d’accord avec tout, mais je respecte vraiment le fait d’assumer fièrement d’être bizarre »
  J’aimerais voir cette attitude plus souvent

• Si on parle des précédents et de l’évolution du terminal, il faudrait au moins mentionner Arcan et cat9
  https://arcan-fe.com/2022/04/…

• Le passage sur « PowerShell gère bien les données structurées » m’a rappelé cette réponse de Jörg W Mittag
  Avec des arguments typés, c’est PowerShell qui s’occupe entièrement du parsing
  Imaginer des onglets Neovim qui s’ouvrent en même temps comme des onglets de fenêtre natifs, c’est vraiment génial
  Travailler juste au-dessus de la couche des appels système, comme en C, Zig ou Rust, aide énormément à comprendre ce qui se passe
  Retirer les couches d’abstraction entre la machine et le programmeur pour atteindre la couche de base, c’est amusant et cela rapproche de la nature profonde du problème
  Comme les bibliothèques standard visent généralement la portabilité, elles finissent par contenir le plus petit dénominateur commun des fonctionnalités des systèmes d’exploitation, alors que programmer devient bien plus agréable quand on peut exploiter au maximum la plateforme
  J’ai beaucoup de respect pour cette attitude qui consiste à dire que, puisque même les fonctions de la bibliothèque standard sont du code écrit par quelqu’un, il ne faut pas les tenir pour acquises et il faut aller les lire
  J’aimerais aussi en savoir plus sur le programme de soutien de Ghostty. Il semble avoir été constitué en organisme à but non lucratif, et je me demande à quel point c’est efficace et viable de manière autonome

• Le PowerShell de Windows a l’avantage d’être entièrement interne selon cette définition, mais comme il est construit sur le framework .NET et peut accéder à presque toutes les API Windows et interopérer avec elles, il n’est en pratique pas tellement limité
  UNIX est par conception externe, et la réponse structurée de Nushell est, si j’ai bien compris, strictement interne, donc moins extensible
  Oils mise sur json ou sa propre extension, json8 pour l’interopérabilité structurée externe, mais les deux paraissent assez limités comparés à PowerShell
  Je me dis qu’on pourrait tous se mettre d’accord pour n’envoyer sur stdout que quelque chose comme msgpack, et transformer tous les terminaux en visualiseurs msgpack. Il faudrait presque lancer une pétition pour ajouter la sérialisation/désérialisation de pipes à libc
  Non seulement les organismes de normalisation des terminaux ont disparu, mais dans le monde des shells aussi il n’y a presque pas eu d’innovation au niveau de la production
  Bash ajoute encore des fonctionnalités qui existaient déjà dans Kornshell, les shells Unix regorgent de pièges que personne ne sait éliminer, et POSIX bouge à peine
  Je m’accroche encore au rêve de voir Oils ou Nushell adoptés par les grandes distributions afin que les gens réalisent que l’innovation dans ce domaine est une bonne chose
  Cela dit, kitty a clairement ouvert la voie dans l’univers des terminaux, et même si la coordination manque, on est au moins arrivés au stade où l’innovation se produit

• J’en suis venu à énormément respecter la manière calme dont Mitchell juge le positif et le négatif
  Il crée un excellent terminal et aime les interfaces en terminal, mais il n’adhère pas à l’idée que le terminal doive tout faire ou qu’il faille pousser cela à l’extrême
  Il se soucie profondément des langages de programmation et de leurs communautés, et souhaite que chaque langage conserve son caractère propre, tout en sachant aussi qu’un langage n’est au fond qu’un moyen au service d’une fin, et que la compréhension des fondements est plus importante
  Il reconnaît ne pas aimer personnellement la communauté Rust, sans pour autant rabaisser ceux qui ressentent les choses autrement
  Sa manière de voir Internet comme un ensemble de tribus sans tomber pour autant dans le tribalisme ni dans la quête de la « seule vraie tribu » donne une impression assez zen

• Je partage l’idée qu’il devrait y avoir davantage de forks personnels/de maintenance, mais je ne sais pas très bien comment l’encourager
  Du côté le moins revendicatif du spectre, on peut ne pas s’intéresser aux aspects orientés entreprise comme les contrats de support payants, et vouloir seulement la commodité de pouvoir installer directement depuis son gestionnaire de paquets préféré
  Il faut d’une manière ou d’une autre réduire le frottement initial entre brew install ou apt install et l’étape où l’on doit gérer soi-même un dépôt cloné et des outils de build
  Des compilateurs plus rapides pourraient aider
  Cela dit, pour les logiciels sensibles du point de vue de la sécurité, il peut être préférable que les utilisateurs ne fassent pas trop de modifications, donc ce frottement peut aussi être une fonctionnalité en soi

• Je suis tout à fait d’accord sur le fait qu’il manque aux UI modernes quelque chose à mi-chemin entre n-screen et les spécifications à base de boutons
  Peut-être qu’on pourrait simplement appeler cela une couche sémantique
  Avec cette couche, des outils de type agent, des outils d’écran principal, l’accessibilité, ainsi que des widgets et contrôles composables deviennent possibles
  n-screen et les boutons ressemblent finalement aux bornes gauche et droite de la quantité de contenu qu’on peut exprimer
  Idéalement, cette couche sémantique devrait aussi apporter des choses comme le multi-curseur, le retour à la ligne par mot plutôt que caractère par caractère, et les overlays (z-index, cell blending, etc.)