Le programme Build It Yourself, à fabriquer soi-même

• Une autre façon de penser les dépendances

  • Une nouvelle perspective est proposée sur les dépendances. Il faut réduire leur usage excessif et aller davantage vers l’écriture directe du code.

• Le problème des dépendances

  • La « consommation de dépendances » désigne la répétition sans fin des mises à jour, correctifs, audits et dépendances transitives que les développeurs installent au nom de la productivité.
  • JavaScript et Rust sont particulièrement vulnérables à ce problème. Par exemple, un nouveau projet Tokio inclut 28 crates, et un projet Rocket monte à 172.

• Le problème de la taille du terminal

  • La crate terminal_size fournit une fonction simple pour mesurer la taille du terminal, mais nécessite plusieurs crates supplémentaires.
  • Cela conduit à devoir compiler des milliers d’autres fonctionnalités.

• La nécessité des dépendances

  • Comme elles sont construites au-dessus de bibliothèques d’abstraction de plateforme, des mises à jour sont nécessaires pour éviter la duplication de code et réduire le temps de compilation.
  • Elles sont aussi souvent une cause majeure de problèmes de sécurité.

• L’objectif du code

  • Le code devrait être écrit de manière à ne pas nécessiter de mises à jour. Dans l’écosystème Rust, le code stable est désavantagé.

• Les avantages d’écrire le code soi-même

  • Écrire le code soi-même évite d’avoir besoin de nouvelles crates et réduit les besoins de maintenance.
  • Des outils comme ChatGPT permettent d’écrire rapidement des implémentations sans dépendances.

• Open source et culture d’entreprise

  • La culture des revues de code en entreprise influence le logiciel open source.
  • Utiliser de nouvelles bibliothèques est perçu positivement.

• La nécessité d’une nouvelle perspective

  • Il faut féliciter les ingénieurs qui écrivent eux-mêmes de petites fonctionnalités.
  • Il faut se montrer méfiant envers les grands graphes de crates.

• Les bibliothèques importantes

  • Il existe aussi des bibliothèques importantes qui résolvent des problèmes complexes, par exemple les bibliothèques graphiques ou les implémentations de protocoles.

• L’importance de construire soi-même

  • Il faut saluer le fait de construire soi-même lorsque c’est pertinent.
  • Il faut reconnaître le mérite des auteurs de bibliothèques qui créent des bibliothèques open source avec peu ou pas de dépendances.

• Conclusion

  • Il faut aller vers une réduction des dépendances et une écriture plus directe du code.
  • minijinja est un exemple de minimisation des dépendances, avec une seule dépendance à serde.

[GN⁺]

Commentaires sur Hacker News

• J’aime le langage Rust, mais je déteste ses problèmes de dépendances. La gestion des dépendances en C++ est meilleure. En C++, on peut contrôler soi-même ses dépendances, alors qu’en Rust, il y en a tellement qu’on finit par abandonner. Même du point de vue de la sécurité, on ne sait pas vraiment ce qu’on déploie. Rust n’a pas de compatibilité ABI et manque d’une culture des bibliothèques partagées. Cela détruit le modèle de distribution des paquets des OS.

• L’API du terminal n’est pas stable. L’ioctl TIOCGWINSZ n’est pas standardisé, et la fonction tcgetwinsize() n’a été ajoutée à POSIX qu’en 2024. Côté Windows, c’est encore plus compliqué.

• J’ai ressuscité une web app créée en 2006. J’ai surconçu son processus de déploiement pour apprendre de nouvelles techniques de CI/CD. Elle utilisait PHP et MySQL, et j’avais écrit la majeure partie du code moi-même. Il ne m’a fallu qu’une heure pour remettre en route cette app vieille de 19 ans. En revanche, l’app Spring Boot utilisée dans mon travail actuel est difficile à mettre à jour à cause de problèmes de dépendances.

• NodeJS a eu un impact énorme sur ma carrière, mais NPM a causé beaucoup de problèmes. Quand on essaie d’ajouter une nouvelle dépendance, elle entre en conflit avec d’autres. Dans le cas d’Expo, il arrive qu’un projet React Native de base ne compile même pas sur Android. Voir que même de gros projets peuvent distribuer des templates non fonctionnels m’a donné confiance.

• L’écosystème Rust a beaucoup de dépendances par rapport à Go. Avec Go, les interfaces sont satisfaites implicitement, donc il n’y a pas besoin de dépendances supplémentaires.

• L’abstraction des bibliothèques a un coût caché. Quand un paquet change de design, cela crée de l’instabilité. Les choses simples sont celles qui survivent le plus longtemps. J’ai vu des problèmes similaires non seulement en Rust, mais aussi dans d’autres langages.

• ChatGPT ou Cursor vont plus vite pour produire rapidement une implémentation sans dépendances. Beaucoup de dépendances à des services SaaS / 3rd party concernent des problèmes déjà résolus.

• Flask et Bottle avaient des fonctionnalités similaires, mais Flask est devenu plus populaire. Bottle tenait dans un seul fichier et n’avait pas de dépendances, ce qui permettait de le copier facilement dans un projet. Mais il n’a pas suivi les pratiques Python modernes et a fini par paraître daté.

• Il faut des ingénieurs compétents capables de développer eux-mêmes des solutions. On peut facilement créer une meilleure solution que les bibliothèques existantes. Dans un projet, j’avais écrit un parseur pour une variante de Markdown, mais mes coéquipiers ont refusé de l’utiliser pour des raisons de maintenance.

• Compiler des centaines de fonctions alors qu’on n’en utilise qu’une seule pose problème. Dans un projet de mise à jour de dépendances 3rd party, on n’utilisait qu’une seule méthode d’une bibliothèque mathématique. J’ai recommandé à l’ingénieur d’écrire directement la méthode lui-même en s’appuyant sur la page Wikipédia. Le problème n’est pas l’usage de dépendances 3rd party en soi, mais le fait qu’on ait besoin d’un moyen de ne prendre qu’une petite partie d’une bibliothèque. Les « microframeworks » pourraient être une solution.