Dernières nouvelles du portage de Fish shell en Rust

 (github.com/fish-shell)
2 points par GN⁺ 2023-11-27 | 1 commentaires | Partager sur WhatsApp
  • Le portage en Rust de fish-shell est « en grande partie » terminé ; selon la méthode de calcul, l’avancement est estimé entre 60 % sur la base des SLOC C++ supprimées et 74 % sur la base du ratio SLOC Rust / SLOC C++
  • Le plus gros chantier restant est le portage du reader et du système d’entrée ; 3,5 k lignes pour le reader, 1,3 k lignes pour la gestion de l’écran, 1 k ligne pour input et 700 lignes pour le pager sont fortement couplées entre elles
  • Tout le code C++ sera supprimé ; l’objectif est de ne pas publier de version partiellement en Rust, mais de faire en sorte qu’une version comme fish 4.0 ne contienne que du Rust et 0 C++
  • Aucun portage Windows n’a jamais été prévu ; le passage à Rust n’est pas une solution au problème de prise en charge de Windows, et les utilisateurs des environnements MSYS2/cygwin craignent que l’absence de cibles correspondantes dans Rust ne bloque les mises à jour
  • Les performances du portage finalisé ne sont pas encore établies ; les premiers résultats sont encourageants, mais certains cas pourraient être environ 20 % plus lents, et une bêta est jugée nécessaire pour la première version Rust

État d’avancement du portage Rust

  • La réécriture de fish-shell en Rust est « en grande partie » terminée
  • Le taux d’avancement varie selon le critère utilisé
    • Sur la base des SLOC C++ supprimées : 60 %
    • Sur la base du ratio SLOC Rust / SLOC C++ : 74 %
  • Une partie du code est un échafaudage dupliqué qui pourra être supprimé une fois le dernier appelant disparu
    • Par exemple, wgetopt a déjà été traduit en Rust, mais la version C++ est conservée jusqu’à ce que le dernier appelant C++ soit porté
    • Cette approche est plus simple que d’ajouter du code de conversion à tous les appelants C++
  • Une fois le dernier appelant disparu et le code dupliqué supprimé, certaines parties seront nettoyées par effet domino

Gros chantiers restants

  • Le principal composant restant est le reader et le système d’entrée
  • Le code concerné est fortement couplé
    • reader : 3,5 k lignes
    • gestion de l’écran : 1,3 k lignes
    • input : 1 k ligne
    • pager : 700 lignes
  • Ensuite, il restera du code résiduel et la dé-C++-isation du système de build
    • Suppression de cmake
    • Passage à un modèle où cargo gère toutes les tâches nécessaires
    • cargo devra aussi prendre en charge la compilation et l’installation de la documentation et des fichiers de completion
  • Le build de fish ne se limite pas à compiler du code Rust : il inclut plusieurs artefacts auxiliaires, ce qui rend la transition non triviale
  • Ce travail n’est pas du type adapté aux « drive-by contributions »

Plan de publication et évolution des versions

  • fish-shell ne prévoit pas de publier de version partiellement en Rust
  • Par exemple, fish 4.0 sera entièrement composé de Rust, avec 0 C++
  • En général, les bêtas et release candidates ont été abandonnées, mais cette transition est jugée suffisamment importante pour justifier une bêta
    • Auparavant, les bêtas et release candidates ont été arrêtées parce qu’elles ne recevaient pas suffisamment de tests
  • Une version intermédiaire 3.7.0 basée sur C++ est également souhaitée avant le passage à la version Rust
    • Elle doit servir de meilleur point de départ pour les plateformes qui ne peuvent pas gérer la version Rust
    • La 3.7.0 correspond à la 3.6.1 avec certaines modifications rétroportées
  • Le travail sur la 3.7.0 se poursuit dans la branche Integration_3.7.0
    • Un CHANGELOG préliminaire est également disponible
    • Les principaux changements incluent les timeouts de combinaisons de touches, des améliorations du history-pager, des corrections de glitches de rendu et un glob plus rapide

Fichiers restants et périmètre concret

  • Au 1er décembre 2023, la liste des fichiers restants est la suivante
src/fish_indent_common.cpp
src/fish_indent.cpp
src/fish_key_reader.cpp
src/builtins/bind.cpp
src/builtins/commandline.cpp
src/fish_tests.cpp
src/pager.cpp
src/reader.cpp
  • Cette liste montre, fichier par fichier, le périmètre restant du portage depuis C++

Corrections de malentendus et contraintes

  • Tout le code C++ sera supprimé
  • Aucun portage Windows n’est prévu, et il n’en a jamais été prévu par le passé
    • C++ est lui aussi bien pris en charge sous Windows, donc Rust en soi ne résout pas le problème du portage Windows
    • Le problème du portage Windows n’est pas le langage, mais le fait que Windows n’est pas Unix
  • Le nom et la mascotte ne changeront pas
  • Il est peu probable que la tagline ajoute « written in Rust »
    • fishshell.com pourra mentionner que le projet est écrit en Rust
    • Lors d’une discussion supplémentaire en septembre 2024, la position consistant à ne pas mettre « written in rust » dans la tagline a été réaffirmée
  • Les performances du portage finalisé ne sont pas encore connues
    • Les premiers résultats sont encourageants
    • Certains cas pourraient être environ 20 % plus lents
    • Même une fois le portage initial terminé, le projet ne sera pas fini et il restera beaucoup de travail

Inquiétudes des utilisateurs Windows et MSYS2/cygwin

  • Un utilisateur explique utiliser fish dans un environnement MSYS2, où les utilitaires POSIX fournis par MSYS2 permettent à fish de bien fonctionner
  • Comme Rust ne fournit pas de cible cygwin ou MSYS2, il craint qu’après la réécriture en Rust, fish ne puisse plus être compilé pour les cibles cygwin ou MSYS2
  • Cet utilisateur estime que le passage à Rust pourrait empêcher certains utilisateurs de fish sous Windows de recevoir les mises à jour
  • Cette inquiétude est présentée non comme une critique du travail ou du langage, mais comme un rappel de la contrainte selon laquelle Windows n’est pas Unix

À lire aussi

1 commentaires

 
GN⁺ 2023-11-27
Commentaires sur Hacker News

  • Si j’ai bien compris, ce qui est impressionnant, c’est de réécrire progressivement de C++ vers Rust tout en gardant le projet fonctionnel jusqu’au bout
    En plus, ça avance très vite, et si vous n’avez pas encore essayé fish, je le recommande vraiment. C’est un shell très agréable à utiliser même sans personnalisation grâce à d’excellents réglages par défaut, et depuis que j’ai quitté bash il y a quelques années, je n’ai jamais eu envie d’y revenir
    Bonus : plus besoin de googler à chaque fois la syntaxe des boucles for de bash, rarement utilisée et peu intuitive

    • Je ne pense pas que ce soit fait de manière progressive
      Ils disent qu’ils ne prévoient pas de publier de version partiellement mélangée avec Rust, et que, par exemple, fish 4.0 sortirait en Rust intégral, 0 % C++. Ils comptent aussi publier une 3.7.0 encore entièrement en C++ afin d’offrir un meilleur point de départ aux plateformes qui ne pourront pas suivre la version Rust
      https://github.com/fish-shell/fish-shell/discussions/10123#d...
    • Pour les scripts, j’utilise toujours Bash, ou bien je sors directement Python/Perl, mais pour l’usage du terminal, Fish est clairement meilleur
    • Comme exemple de boucle Bash facile à retenir, un index incrémental s’écrit for ((i = 0; i < 10; i++)); do echo $i; done
      Pour parcourir un tableau, on peut définir foo[0]=a, foo[1]=b, puis utiliser for i in ${foo[@]}; do echo $i; done

  • Les motivations de la réécriture sont expliquées plus en détail ici
    https://github.com/fish-shell/fish-shell/pull/9512#issuecomm...

    • Le message du mainteneur est à la fois mûr, logique, avec juste ce qu’il faut d’humour et de fermeté ; ça m’a fait passer de « je devrais peut-être essayer Fish un jour » à j’ai probablement raté un excellent projet
    • Trouver qu’un portage vers C++17 est « trop pénible », tout en jugeant acceptable de tout réécrire dans un nouveau langage, en dit long
      Au fond, il est difficile d’aller contre cette tendance générale du monde du développement à courir après la nouveauté brillante. Cela dit, même si je n’utilise pas Fish, je lui souhaite de réussir

  • En tant qu’utilisateur quotidien de Fish sur environ quatre systèmes d’exploitation et grand amateur du shell, cette réécriture me rend vraiment enthousiaste, et vu la taille et la complexité de la base de code, la vitesse d’avancement est impressionnante
    J’imagine aussi que cela facilitera les contributions pour beaucoup de gens, moi compris. Un point moins remarqué mais encore plus prometteur à mes yeux est le projet de faire passer fish à UTF-8 au lieu de wchar_t à l’avenir. UCS2 et UTF-16 ont été une plaie pour les logiciels, et Rust rend la gestion d’UTF-8 bien plus simple

    • Prendre en charge plusieurs compilateurs dans une même base de code ajoute de la complexité
      sizeof(wchar_t) vaut 2 octets avec MSVC, donc UTF-16, alors qu’avec gcc il vaut 4 octets, donc UTF-32

  • Fish est un shell sous-estimé
    Il fait des choix forts, comme abandonner la compatibilité POSIX, et au final cela donne un très bon shell. Je l’utilise depuis plus de dix ans et je l’aime toujours autant
    Le scripting Fish est aussi très agréable, une sorte de bash ergonomique. Aucun projet n’est sans défaut, mais il ne m’a jamais réellement empêché de faire ce que je voulais faire

  • J’utilise zsh + spaceship, et je me demande quels seraient les avantages à passer à Fish comme shell principal
    Je fais peu de scripts bash, donc l’aspect scripting m’importe moins

    • Si votre zsh est déjà configuré exactement comme vous le voulez, il n’y a probablement pas énormément d’avantages
      Le grand point fort de Fish, c’est d’être très proche du shell idéal dès l’installation. L’autocomplétion fonctionne immédiatement, l’exploration de l’historique est simple, la complétion basée sur l’historique aussi, et choisir un prompt est aussi facile que d’ouvrir un navigateur. On peut le personnaliser en profondeur comme zsh, mais même par défaut c’est déjà un très bon shell
    • Si j’ai choisi Fish plutôt que zsh en 2017, c’est parce que les fonctionnalités que je voulais étaient incluses de base, et qu’il me paraissait nettement plus rapide
      Depuis, je ne passe quasiment plus de temps à faire de la maintenance de configuration du shell, ce qui est appréciable
    • La vitesse
      Fish intègre de base beaucoup de choses qui demandaient des plugins sous zsh. Les plugins zsh étaient lents au point que le démarrage du shell dépassait les 3 secondes, alors que Fish démarre bien plus vite, même avec des plugins
    • La première fois que j’ai créé un fichier fish_prompt.fish dans le bon répertoire, puis écrit dedans une fonction fish_prompt qui affiche une chaîne sur la sortie standard pour construire moi-même le prompt du shell, j’ai failli supprimer zsh
      Après ça, il devient difficile de revenir à la méthode consistant à entasser toutes sortes de choses dans $PS1 en espérant que ça fonctionne. Je recommande de l’essayer quelques jours, ne serait-ce que pour voir quelles choses que vous considériez comme acquises sont en fait spécifiques à un shell. Au pire, vous vous direz simplement « ce n’est pas mon truc » et vous reviendrez à bash, zsh ou au shell que vous préférez
    • Je suis passé de zsh à Fish il y a quelques années ; les fonctionnalités sont à peu près similaires, mais le fichier de configuration Fish fait environ 10 % de la taille de ma configuration zsh
      La plupart de ce que je veux est fourni par défaut, et aujourd’hui je n’utilise plus qu’un seul plugin, fzf.fish

  • Il y a de bonnes chances que l’un des shells les plus rapides devienne encore plus rapide
    Depuis que je suis passé de zsh à Fish, ma productivité dans le terminal a beaucoup augmenté

    • Je ne parierais pas là-dessus
      D’après le lien, ils ne savent pas encore vraiment quelles seront les performances du port terminé. Les premiers résultats sont encourageants, mais dans certains cas, il est tout à fait possible que ce soit environ 20 % plus lent
    • Je ne pense pas qu’il y ait un si grand écart de performances entre C++ et Rust
      Les deux sont pratiquement au coude-à-coude, et il n’y aura sans doute pas de vainqueur clair
    • Je me demande dans quels workflows les performances du shell deviennent un goulot d’étranglement
      J’ai toujours vu ça comme une sorte de code de liaison qui délègue généralement le travail ailleurs. Il peut y avoir des questions d’efficacité des pipes, ou peut-être des gens un peu particuliers qui écrivent des programmes entiers en bash, mais vu tous les gains de confort qu’apporte Fish, citer la vitesse comme avantage principal me paraît un peu surprenant
    • Je ne tape ni ne gère mes tâches assez vite pour que les différences entre C, C++, Rust ou d’autres langages aient un impact significatif ; je me demande donc si Fish apporte autre chose de plus

  • J’utilise Fish depuis un an
    Je n’aime pas le fait qu’il casse la compatibilité standard au point d’empêcher certains scripts comme gvm ou nvm de fonctionner, mais il intègre toutes les fonctionnalités qu’on configure généralement soi-même dans zsh. Après avoir essayé de maintenir une configuration zsh sur plusieurs machines, j’ai abandonné et je suis passé partout au Fish par défaut
    Comme ça fonctionne déjà bien, je ne vois pas très bien ce qu’un portage en Rust apporterait. Si c’est pour des raisons de sécurité, on peut se dire qu’il y a déjà quelque chose de malveillant installé sur le système capable de modifier Fish

    • Comme indiqué dans la discussion initiale sur Rust, il y a plusieurs raisons de migrer vers Rust
      Il s’agit surtout de faciliter le recrutement de contributeurs et d’ajouter des modes asynchrones/parallèles sans inquiéter les mainteneurs
      [1] https://github.com/fish-shell/fish-shell/pull/9512

  • Fish est excellent
    Je suis passé de ZSH+Prezto à Fish seul, sans rien regretter, et c’est nettement plus rapide. Tous mes serveurs tournent encore avec bash et j’utilise toujours des scripts bash, mais pour les tâches quotidiennes dans le terminal, Fish suffit largement

  • Fish m’a toujours intrigué, mais sa non-compatibilité POSIX me rebutait
    Je me demande si certains peuvent partager les problèmes rencontrés sur ce point et les moyens de contournement

    • Fish n’est pas conçu pour remplacer les scripts bash/shell, mais pour servir de shell interactif, donc le respect de POSIX n’est pas vraiment un problème en pratique
      L’inconvénient, c’est qu’il faut un petit changement de contexte. C’est particulièrement vrai si on a utilisé bash/zsh toute sa vie. Personnellement, je trouve facile de distinguer les moments où le shell sert d’interface utilisateur de ceux où bash/sh sert d’interpréteur, mais ce n’est peut-être pas intuitif pour tout le monde
      De plus, depuis que je n’utilise plus un shell compatible POSIX au quotidien, j’ai tendance à faire passer plus vite dans un langage généraliste les scripts que j’aurais autrefois écrits en bash
    • Les scripts Bash/zsh peuvent simplement être exécutés avec Bash/zsh : bash script.sh
      Au début, l’incompatibilité POSIX de Fish me gênait, mais après avoir appris un peu sa syntaxe différente et m’en être affranchi, je trouve que sa syntaxe plus rationnelle vaut largement l’effort. Aujourd’hui, j’apprécie beaucoup plus le terminal
      Et puis, 90 % du temps, il n’y a pas besoin de compatibilité POSIX, et beaucoup de scripts ou extensions prennent désormais Fish en charge. En entreprise, on continue à utiliser Bash/zsh, qui restent le standard

  • Je me demande pourquoi le passage à Rust est nécessaire
    La base de code en C++ était-elle devenue trop difficile à maintenir ?