Ruby subit une stagnation face aux réécritures Rust et aux LLM

Contexte du discours de DHH

Lors du keynote de DHH à RailsWorld, l’orateur a déclaré que la réécriture de la fonction HEY en Rust était plus performante et que Rails n’était plus nécessaire. Cette affirmation reflète une tendance à privilégier les réécritures bas‑niveau au détriment du framework Ruby on Rails, qui a longtemps servi de base aux applications web. Le propos a déclenché une réaction au sein de la communauté, soulignant le désengagement de certains leaders vis‑à‑vis de l’écosystème Ruby.

Pression des LLM et de l’automatisation du code

Le texte indique que les grands modèles de langage (LLM) sont désormais capables de générer du code Ruby, rendant la saisie manuelle de chaque ligne peu viable. Cette évolution impose aux développeurs de repenser leurs flux de travail : au lieu d’écrire du code ligne par ligne, ils doivent intégrer des outils de génération assistée et valider les sorties automatisées. L’impact direct est une réduction du temps consacré à la rédaction de code, mais aussi une exposition accrue aux erreurs introduites par les modèles, nécessitant des stratégies de test plus rigoureuses.

Limites techniques de l’écosystème Ruby

Plusieurs lacunes sont mentionnées : l’absence de bibliothèques fiables pour la génération de PDF, le manque de support natif pour les interfaces graphiques, et la difficulté à créer des gems natifs sans manipuler manuellement des structures internes (ubf_unblock, INT2FIX). Ces problèmes augmentent le coût de développement, surtout lorsqu’ils s’ajoutent à des cycles de release Rails déjà longs dans les grandes entreprises. Le texte souligne également que les pools de connexion de bases de données restent une source fréquente de bugs, ce qui indique que les mécanismes de gestion de ressources n’ont pas évolué au même rythme que les exigences de scalabilité.

Propositions d’évolution et comparaison avec d’autres stacks

Le fil de discussion cite plusieurs axes d’amélioration : accélérer Ruby de 10 fois, introduire un système de types comparable à Rust, intégrer SQLite3 avec un protocole de réplication, et renforcer la prise en charge de la concurrence. Ces suggestions sont comparées à Phoenix, le framework Elixir qui propose déjà la fonctionnalité « presence », démontrant que la résolution de problèmes de présence et de synchronisation en temps réel est possible dans d’autres écosystèmes. L’auteur note que, malgré l’intérêt pour Rust en raison de sa vitesse et de son système de types, Ruby conserve des atouts esthétiques (syntaxe sans parenthèses, conventions de nommage) qui attirent encore des développeurs.

Perspectives pour la communauté Ruby

Le texte conclut que le désengagement de figures influentes ne contraint pas les contributeurs restants. La disponibilité de nouveaux outils, la montée des LLM et la pression pour des performances accrues créent un environnement où les développeurs peuvent choisir d’investir dans des réécritures Rust, d’attendre des améliorations natives de Ruby, ou de migrer vers d’autres langages. La décision dépendra du coût d’intégration des solutions externes (ex. : SQLite3 réplication) versus les gains de productivité offerts par l’automatisation du code.