Un pari risqué qui porte ses fruits
Un développeur indépendant a entrepris de migrer l’intégralité de son projet personnel, initialement écrit en Rust, vers Ruby et le framework Ruby on Rails. L’application, qui comptait environ 14 943 lignes de code Rust réparties dans une crate isolée dédiée au web (utilisant Tera et Axum), a été convertie en un seul passage par un modèle de langage local exécuté sur une carte graphique 4090 Ti. La conversion a duré une trentaine de minutes et a produit 3 322 lignes de code Ruby, soit une réduction de 77 % du nombre de lignes.
Le développeur, qui se décrit comme « un homme libre avec des jetons illimités » grâce à son matériel personnel, indique n’avoir pas encore testé l’application convertie. Il a néanmoins parcouru le code Ruby généré et le juge « propre et idiomatique » pour son œil de développeur expérimenté, tout en reconnaissant que quelques bugs pourraient subsister.
Une analyse comparative avant la migration
Avant de lancer la conversion automatique, le développeur a demandé à plusieurs instances du modèle local d’évaluer les gains potentiels en matière de complexité, stabilité et testabilité. Il a établi un tableau comparatif notant chaque aspect sur 100 points, entre la pile Rust (Rust/Axum/Diesel), Ruby on Rails seul, et Ruby on Rails enrichi du système de typage Sorbet.
Le tableau montre que Ruby surpasse Rust dans la plupart des critères pour un développeur solo. Rails obtient une note de 90 sur 100 pour la rapidité de développement, contre 40 pour Rust. La testabilité unitaire est évaluée à 90 contre 20, et la testabilité des tests d’intégration à 85 contre 30. En revanche, Rust conserve des scores très élevés en sécurité (95 contre 55 pour Ruby seul) et en performance (95 contre 50). L’ajout de Sorbet remonte la sécurité à 80 tout en maintenant la plupart des atouts de Rails. La somme totale des notes atteint 710 pour Rails, 695 pour Rails + Sorbet, contre 480 pour l’empilement Rust.
« Au final, il semble que j’aurais 1,47 fois plus de chances d’obtenir de meilleurs résultats si l’application était une application Ruby on Rails », conclut le développeur.
Des tests bien plus simples
L’un des arguments majeurs en faveur de la migration réside dans la facilité des tests. Le développeur illustre une différence frappante entre les deux approches. En Ruby, un test d’appel à un modèle de langage peut s’écrire de manière concise à l’aide d’une cassette VCR, tandis qu’en Rust, la mise en place d’un mock nécessite des structures de données et des mécanismes de synchronisation complexes recourant à des pointeurs atomiques et des verrous en lecture-écriture.
Le développeur souligne également que la compilation du projet Rust prenait une dizaine de secondes, un temps qu’il juge élevé pour un projet de cette taille en raison de toutes les dépendances entraînées. En comparaison, Ruby, avec Rails, fournit un écosystème « batteries incluses » qui évite ces lourdeurs.
Un projet relancé par l’IA locale
Le passage à Ruby a été motivé par une curiosité technique et la disponibilité d’un modèle de langage local performant. Le développeur a commencé par faire analyser son code Rust par plusieurs instances, avant de lancer la conversion one-shot. Il envisage désormais d’ajouter des types via des agents pour renforcer la sécurité du code Ruby.
« Ruby et Rails se portent plutôt bien aujourd’hui », note-t-il. Il cite notamment l’initiative Sorbet qui apporte un typage optionnel au langage. La ténuité syntaxique du Ruby a été un facteur déterminant dans la réduction drastique du volume de code.
Implications pour les développeurs solo
Cette expérience illustre comment un développeur isolé peut, grâce à l’IA locale, franchir le pas d’une migration technologique majeure sans dépendre de services cloud ni de budgets importants. La réduction des lignes de code facilite la maintenance et accélère les cycles de développement. Toutefois, le développeur reconnaît que la stabilité pourrait en pâtir sans les garanties offertes par le système de types de Rust, même si l’ajout de Sorbet permet de compenser partiellement.
Le code Ruby généré n’a pas encore été exécuté ; le développeur prévoit de l’examiner plus avant et de le mettre en production si les tests s’avèrent concluants.