Loco 1.0 : le « Rails de Rust » est enfin arrivé ? 🚂🦀

Le 29 juillet 2026, Loco passait en version 1.0. Pour les habitués de ce blog, c'est le genre d'annonce qui mérite qu'on s'y attarde : je vous parle depuis longtemps de ma philosophie Rust-first — vérifier s'il existe une alternative en Rust avant d'adopter un outil, comme je l'avais fait pour le monitoring avec Temps et RustRak ou pour le desktop avec Tauri. 🚂🦀

C'est quoi, Loco ? 🧰

Loco se décrit lui-même comme « The one-person framework for Rust for side-projects and startups » : un framework batteries-included construit sur Axum, qui veut vous donner l'expérience « Rails/Django » en Rust — sans vous faire réimplémenter l'authentification, les migrations, la configuration ou le scaffolding à chaque projet.

Pourquoi 2026 est l'année des « batteries-included » 🧩

La sortie de Loco 1.0 arrive dans un contexte très particulier. Le 25 juin 2026, le blog JetBrains publiait un article devenu vite célèbre, écrit par les co-mainteneurs de cot.rs (l'autre framework batteries-included de l'écosystème), intitulé « Rust Web Development 2026: The Problems Nobody Talks About ». Le constat est sans appel :

• Debug async difficile — un simple panic! peut générer un backtrace de 100 frames, avec le vrai problème perdu entre les frames 9 et 10
• Pas d'async drop en Rust stable — et un pinning qui reste pénible au quotidien
• ORM à trois représentations — avec Diesel, vous définissez votre modèle en Rust, écrivez les migrations SQL, et maintenez un schema.rs généré : trois représentations de la même donnée
• Gestion d'erreurs incohérente — Axum expose deux mécanismes (IntoResponse vs HandleErrorLayer), Actix-web a son ResponseError qui ne donne accès qu'à l'erreur elle-même
• Temps de compilation — les generics seuls peuvent faire passer un binaire de ~2 Mo à 37 Mo en mode release

La conclusion des auteurs : « Batteries-included frameworks like Loco.rs and cot.rs are closing the gap, but we're not at Django or Rails level yet. » Autrement dit : le problème est identifié, et Loco fait partie de la réponse.

Loco vs les alternatives : le tableau de bord 📊

Mon verdict : faut-il l'adopter ? ⚖️

La réponse honnête : ça dépend de votre projet, mais la direction est excellente.

Adoptez Loco si : vous montez un side-project ou un service CRUD en solo, vous voulez du Rust pour la performance et la fiabilité, mais vous refusez de perdre trois semaines à assembler auth + ORM + config + migrations. Loco vous donne un squelette qui tourne dès le premier cargo loco start, et vous gardez tout l'écosystème Axum/Tower sous le capot quand il faut descendre d'un cran.

Réfléchissez si : vous avez déjà une base Axum bien structurée avec vos propres conventions — migrer vers Loco pour « la mode » n'a pas de sens. Et si vous visez un très gros monolithe avec des besoins très spécifiques, l'écosystème Rust n'est pas encore au niveau de Django/Rails — les auteurs eux-mêmes le disent.

Ce qui est certain, c'est que la barre de l'expérience développeur en Rust web vient de monter d'un cran. Entre Axum 0.8 qui reste la référence des APIs, Actix-web 4.14 qui garde la couronne des benchmarks purs, et maintenant Loco 1.0 pour celles et ceux qui veulent du « tout compris », il y a enfin un choix pour chaque profil.

Et la suite ? 🔭

De mon côté, je vais monter un petit projet de démo avec Loco pour vous montrer un cas concret de bout en bout — inscription, CRUD, et déploiement. Si ça vous intéresse, dites-le moi en commentaire, et si vous ne l'avez pas encore fait, jetez un œil à mon article sur les assistants de codage IA auto-hébergés pour compléter votre setup de dev Rust. 🚀