EuroRust 2025, notre retour sur l’édition Parisienne
La conférence européenne de Rust a établi son siège à Paris, à la Cité des sciences et de l’industrie, pour son édition 2025.
Nous vous proposons dans cet article un bref aperçu des différentes conférences auxquelles nous avons assisté ! 🦀
Section intitulée are-we-desktop-yetAre we desktop yet?
La keynote d’ouverture a été présentée par Victoria Brekenfeld, qui travaille pour System76 sur l’environnement de bureau Cosmic.
Cosmic est, à l’instar de Gnome ou KDE, un environnement de bureau entièrement écrit en Rust, intégrant un gestionnaire de fenêtres en tuiles (tiling window manager) comme i3, Sway ou Hyprland.
Les « Are we… yet? » sont des thèmes majeurs dans la communauté Rust, permettant de suivre l’évolution du langage, de sa communauté et des bibliothèques associées sur un sujet particulier.
Avant de répondre à la question, la conférence a abordé ce qui définit un environnement de bureau : la gestion des fenêtres, un lanceur d’applications (launcher), un menu, la composition graphique, la gestion des entrées/sorties, et de nombreuses applications de base pour gérer le système.
La majorité de ces besoins repose largement sur la gestion de l’interface utilisateur. S’appuyant sur la bibliothèque « iced », Cosmic a développé d’autres « crates » (modules) par-dessus pour pallier certaines de ses lacunes, notamment « cosmic-text » pour le rendu du texte et « libcosmic », la bibliothèque de base de Cosmic, qui comprend de nombreux widgets réutilisables pour les différentes applications.
De son point de vue, Rust est désormais prêt pour les applications avec interface graphique, grâce au travail de nombreuses personnes.
Elle est ensuite revenue sur son parcours et son travail au sein de Cosmic, notamment sur le compositeur, qui est le composant le plus complexe d’un environnement de bureau, car il assure le lien entre les applications et le système.
Section intitulée exemplary-by-designExemplary by Design
Cette conférence, de Jacob Pratt, a abordé les bonnes pratiques actuelles pour maintenir un projet Rust de grande ampleur. On y retrouve les grands classiques, ce qui constitue une bonne piqûre de rappel :
- Séparer les implémentations système dans différents fichiers (Windows / macOS / Linux) ;
- Séparer votre projet Rust en plusieurs crates indépendantes s’il devient trop gros ;
- Utiliser le système de workspace de Rust quand on a plusieurs crates ;
- Utiliser rust-analyzer sur son IDE (et même le personnaliser si besoin) ;
- Utiliser l’outillage de Rust : fmt / clippy ;
- Favoriser les itérateurs aux boucles for ;
- Cacher les enums derrière un objet si possible, pour pouvoir modifier l’enum sans casser la compatibilité ;
- Utiliser non_exhaustive sur les enums si elles sont publiques ;
- Utiliser un système de builder en mode fluent interface pour la création d’objets complexes et la gestion des valeurs par défaut, même si ce point sera certainement obsolète dans le futur avec les default_field_values ;
- Utiliser quickcheck et MIRI pour tout ce qui est unsafe ;
- cargo-llvm-cov pour la couverture de code (coverage) ;
- cargo-deny pour les problèmes de sécurité (security issues) ;
- cargo-semver-check pour vérifier les promesses de compatibilité descendante (BC promises).
Section intitulée a-deep-dive-into-serde-driven-reflectionA Deep Dive into Serde-Driven Reflection
Ohad Ravid est l’auteur de la crate wmi (Windows Management Instrumentation), un package qui permet d’interroger Windows comme s’il s’agissait d’une base de données SQL. Par exemple, il est possible de récupérer la version du système en exécutant la requête : SELECT Version FROM Win32\_OperatingSystem.
Afin d’améliorer l’expérience développeur (DX), la bibliothèque permet de récupérer toutes les informations sous forme de structure ou de valeur typée.
Pour parvenir à ce résultat, elle utilise serde comme moteur de réflexion afin de construire sa propre structure en Rust, laquelle sera ensuite convertie en requête SQL et hydratée avec le résultat.
Si vous n’êtes pas familier avec les rouages internes de Serde, il peut être intéressant de visionner cette conférence pour mieux comprendre cette bibliothèque.
Section intitulée znext-solver-what-why-and-when-Znext-solver: what, why, and when
Le solver en Rust est le moteur qui permet de valider et d’inférer les types génériques des traits et des structures en Rust.
Bien que très puissant, ce dernier présente actuellement de nombreux bogues, et certaines fonctionnalités ne peuvent pas être réalisées avec lui.
lcnr nous a présenté les travaux autour de la réécriture de ce solver et ce qui nous attend dans les prochaines versions de Rust.
Vous pouvez d’ores et déjà tester ce solver en version nightly !
Section intitulée rendering-at-1-million-pixels-millisecond-with-gpuiRendering at 1 million pixels / millisecond with GPUI
La dernière conférence de la première journée, présentée par Conrad Irwin, était une ode à la performance et une critique des inconvénients quotidiens liés à l’attente constante qu’une application termine une tâche, que ce soit un IDE, une compilation, une intégration continue, etc.
Le point essentiel est que l’attente est une perte de temps, source d’énervement, ce qui se ressent tout au long de la journée. Alors que lorsqu’une application est rapide, on ne la remarque pas forcément, mais son utilisation devient agréable et laisse un bon souvenir, nous incitant à le réutiliser sans même en avoir conscience.
L’orateur est ensuite revenu sur son parcours et celui de son équipe, qui provenaient de l’IDE Atom, propriété de GitHub, mais abandonné suite au rachat par Microsoft, car faisant doublon avec VSCode.
Atom, initialement créé avec des composants React et Electron (ce dernier ayant d’ailleurs été créé par la même équipe pour Atom), était relativement « lent » et ils ne voulaient pas reproduire les mêmes erreurs. Ils se sont donc tournés vers Rust, mais ont perdu la productivité de développement qu’ils pouvaient avoir avec React. Ils ont donc créé GPUI : une bibliothèque permettant de représenter son interface sous forme de composants, exactement comme React, mais en Rust. Ils ont ainsi pu réécrire toute leur interface en une semaine et sortir une première version.
On peut noter, en outre, qu’un intégrateur ne connaissant pas React a pu très rapidement prendre en main la bibliothèque sans trop de problèmes, ce qui les a confortés dans la vision de celle-ci.
Section intitulée rewrite-optimize-repeat-our-journey-porting-a-triemap-from-c-to-rustRewrite, Optimize, Repeat: Our Journey Porting a Triemap from C to Rust
Luca Palmieri, auteur du livre Zero to Production in Rust, a présenté lors d’Eurorust 2025 a migration du moteur de requêtes de RedisSearch, Redis Query Engine. Le défi majeur réside dans la réécriture en Rust d’un code C de 63 000 lignes, notoirement complexe et sujet aux segfaults. Contrairement à RedisJSON, déjà migré en Rust mais plus simple, le moteur de requêtes est un « nœud de spaghetti » qui nécessite une approche itérative.
La stratégie de base se décompose en plusieurs étapes :
- Modularisation : Représenter le code C sous forme de modules distincts.
- Identification des dépendances : Trouver les modules sans dépendances.
- Réécriture en Rust : Migrer ces modules isolés vers Rust.
- Intégration : Intégrer les modules Rust au code C existant.
- Répétition : Remonter la hiérarchie des modules, en répétant le processus.
Cette approche n’est malheureusement pas adaptée pour Redis Query Engine, car tous les modules sont dépendants entre eux et il devient alors compliqué de trouver les modules sans dépendances, l’approche a donc été légèrement modifié pour autoriser l’appel de code C à l’intérieur d’un module Rust permettant ainsi de convertir n’importe quel module peu importe ses dépendances.
Un exemple concret est la réécriture de TrieMap, une structure cruciale pour l’indexation et la recherche par préfixe. La complexité de sa structure mémoire en C pour des raisons de performance a cependant posé un défi majeur.
Pour garantir la qualité de la migration, une « baseline » a été établie avec une API publique pour mesurer les performances et faciliter les tests comparatifs entre les deux implémentations. Après une première implémentation trop lente, l’utilisation de blocs unsafe a été nécessaire pour reproduire le même agencement mémoire qu’en C. Afin de maîtriser la complexité et de limiter les commentaires, les blocs unsafe ont été regroupés au sein d’une API privée, avec l’aide de l’outil muri pour détecter les problèmes de mémoire et des contraintes clippy pour la documentation.
Le résultat final est remarquable : l’implémentation en Rust a non seulement reproduit les fonctionnalités, mais a également surpassé les performances de la version en C.
Section intitulée how-rust-compilesHow Rust compiles
Noratrieb, membre de l’équipe de compilation de Rust depuis 3 ans, nous a montré ce qu’il se passe lors d’un cargo build.
La compilation est plus ou moins séparée en 2 phases : le frontend (pour gérer tout ce qui est syntaxe, macros, borrow checker, etc.) et le backend (pour la compilation et le codegen).
Nous nous sommes beaucoup plus attardés sur la partie backend, et ce qui pouvait la ralentir en fonction de la manière dont notre code est écrit.
Par exemple, en utilisant l’attribut #[inline], toutes les dépendances qui utilisent cette fonction n’auront pas directement la compilation de cette fonction, mais une représentation intermédiaire que chacun devra ensuite optimiser. Ainsi, une fonction #[inline] utilisée à de nombreux endroits ralentira la compilation mais pourra accélérer l’exécution si certaines optimisations sont possibles grâce à cela.
Lorsque l’on expose des génériques en mode public, il y a aussi une représentation intermédiaire, car Rust ne connaît pas encore toutes les possibilités qu’il doit prendre en compte, ce qui ralentit également la compilation.
Au final, il y aura toujours un compromis à choisir entre la vitesse de compilation, la vitesse de développement (productivité) et la vitesse d’exécution.
Enfin, nous avons également vu ce que certaines optimisations changeaient lors de la compilation, notamment si l’on choisit lto="fat" ou lto="thin" dans le profil de compilation.
Si vous rencontrez des lenteurs de compilation, je vous recommande grandement cette conférence qui permet de faire la lumière sur certains sujets.
Section intitulée misusing-const-for-fn-and-profitMisusing Const for Fn and Profit
Tristram Oaten, l’auteur des podcasts No Boilerplate, nous a présenté une conférence décalée sur l’utilisation des const (et des macros) au sein de Rust et tout ce qu’on peut en faire.
Étant donné que Rust permet de créer des macros avec du code Rust, les possibilités sont infinies. On peut notamment citer la bibliothèque sqlx qui effectue des requêtes SQL lors de la compilation de votre projet Rust afin de générer du code optimisé et fortement typé en fonction de votre schéma.
Section intitulée building-a-lightning-fast-search-engineBuilding a lightning-fast search engine
Clément Renault, le CTO de Meilisearch, est revenu sur son parcours de développeur, notamment au sein de Veepee, et ce qui l’a amené à créer Meilisearch, un moteur de recherche open source très performant.
Il nous a aussi présenté les travaux en cours, portant notamment sur la réplication et le sharding de Meilisearch, ainsi que sur l’intégration de l’IA via le stockage et la recherche par vector embeddings.
La problématique est que la plupart des outils existants fonctionnent uniquement avec des données en mémoire, ce qui n’est pas envisageable au vu des volumes de données possibles dans leur moteur de recherche.
Ils ont donc créé arroy qui permet de stocker ces vecteurs sur LMDB (un stockage clé-valeur sur disque mappé en mémoire). Cependant, cette solution présente encore de nombreux problèmes de scalabilité, notamment en ce qui concerne la performance de recherche et d’indexation lors de l’ajout, de la mise à jour ou de la suppression des vecteurs.
Pour résoudre ce problème, ils travaillent depuis peu sur hannoy, basé sur arroy, et qui utilise des indices HNSW pour accélérer considérablement la vitesse de recherche et l’indexation lorsque l’on veut trouver des vecteurs proches.
Section intitulée eurorust-2026EuroRust 2026 🇪🇸
L’édition 2025 s’est achevée avec succès, malgré quelques imprévus initiaux rapidement résolus. Nous attendons avec impatience l’édition de l’année prochaine à Barcelone, qui promet encore une fois de rassembler la communauté européenne autour de conférences de grande qualité.
Cet article porte sur la conférence EuroRust 2025.
