Sylvestre Ledru (Mozilla) : de Firefox au noyau Linux, la fulgurante ascension du Rust
Oxydation galopante
Le langage Rust est désormais presque partout. Dans une série d’entretiens, nous nous penchons sur son parcours, son évolution et surtout son utilisation aujourd’hui. Nous avons ainsi interrogé Sylvestre Ledru, directeur de l’ingénierie chez Mozilla et lead sur le projet de version Rust des Core Utils de Linux, intégrée récemment dans Ubuntu 25.10.
Le langage Rust a été créé par Mozilla. De projet personnel, il est devenu officiellement incubé par la fondation en 2009. Il a rapidement été vu comme pouvant déboucher sur d’importantes améliorations dans les logiciels, notamment Firefox. Nous étions revenus sur son histoire à l’occasion des 10 ans de la version 1.0 en mai dernier. Il est aujourd’hui géré par une fondation indépendante, dirigée actuellement par Rebecca Rumbul.
Le langage Rust fait régulièrement parler de lui, en grande partie pour deux de ses qualités : il est « memory safe » tout en préservant les performances du C++. Nous avions expliqué ces qualités en 2019, quand Microsoft indiquait se pencher sur le langage pour sa programmation système. Un projet devenu réalité depuis, la version 24H2 de Windows 11 ayant été la première version à intégrer du Rust dans le noyau du système.
Dans une nouvelle série d’entretiens, nous nous penchons sur l’utilisation faite du Rust dans plusieurs entreprises. Nous ouvrons le bal avec Sylvestre Ledru, directeur de l’ingénierie chez Mozilla. En plus d’avoir été témoin de l’arrivée du langage chez l’éditeur et de ses premières utilisations dans Firefox, il est l’auteur de la version Rust de coreutils récemment intégrée dans Ubuntu 25.10.
>> Qu’est-ce qui vous a dirigé vers le Rust ?
Initialement, quand Mozilla a créé le Rust, c’est parce qu’on pensait qu’il y avait une meilleure façon de programmer. La vraie raison, c’est que nous avons estimé que nous ne savions pas – et que personne ne sait – écrire du code C ou C++ qui soit réellement sûr et parallèle. On passait un temps fou à corriger des bugs qui étaient liés au langage de programmation, et pas à nos erreurs de programmation logiques.
Je pense que tous les gens qui peuvent discuter aujourd’hui du Rust vous diront la même chose : 60 % des failles de sécurité sont causées par des problématiques de gestion de la mémoire, à la fois en C et en C++(les problèmes de pointeurs). Le parallélisme, c’est aussi quelque chose de très compliqué à faire correctement. Ce sont ces raisons qui ont poussé Mozilla à développer Rust.
Commentaires (8)
Le 04/11/2025 à 11h41
Pourquoi remplacer des applications en python ou perl si le seul souci est la gestion de la mémoire ?
(attention, je suis d'accord qu'on peut avoir d'autres bonnes raisons)
Le 04/11/2025 à 12h48
Modifié le 04/11/2025 à 13h03
Modifié le 04/11/2025 à 13h05
Le 04/11/2025 à 13h47
Maintenant, si on reste dans le monde réel, il n'y a sans doutes pas que la question de la mémoire.
Par exemple, le simple fait qu'une application soit en Perl est déjà une bonne raison de la réécrire
Le 04/11/2025 à 14h18
Le 04/11/2025 à 16h28
Seul DetunizedGravity a répondu à ma question, parce que pour les performances et la lisibilité du langage, il me semblait avoir pris soin de les écarter de ma qestion.
Et j'avais pris soin de rester vague dans ma formulation concernant la mémoire.
Je ne saurais garantir que perl et python sont memory safe, mais il me semble qu'il est plus facile de rester dans les clous qu'en C (j'ai utilisé ces 3 langages dans ma carrière professionnelle).
Ce que je veux dire, c'est qu'il me semble que Sylvestre Ledru en fait un peu trop sur ce coup:
Je comprends qu'on veuille changer de langage pour une application, et aussi que dans ce cas le Rust est un bon choix. Simplement, il me parait exagéré de dire que c'est à cause de la gestion mémoire que ce changement est envisagé.
D'accord, pas d'accord ?
Le 04/11/2025 à 20h41
Il est indéniable que Rust a montré une voie interessante pour le futur sur le safety memory. Pourtant, il n'a pas vraiment pris. Python a été adopté bien plus rapidement que lui et sa popularité mesuré par TIOBE montre qu'il diminue de plus en plus, au point d'être derrière l'assembleur et même Ada.
Rust pour le bas niveau, on attend toujours un vrai truc. On n'a toujours pas de vrais drivers Linux pour des composants critiques, beaucoup sont en dev mais toujours pas de cas concrets sur des éléments comme le PCI-E, le scheduler, le RDMA... ça ne veut pas dire qu'il n'y a pas de petite pétite comme Redox.
L'autre soucis de Rust, c'est sa librairie extrêmement pauvre. On peut rien faire de sérieux avec sans devoir passer du temps à chercher à trouver une crate. Certes c'est une feature mais pour un langage qui vise le bas-niveau, je suis pas convaincue du tout. C++, avec ses qualités et ses défauts, fait largement mieux.
En terme pro, dans ma boîte malgré que Rust était bien positionné pour un projet le fait devoir utiliser cargo avec ces 1000 et 1 dépendances nous a finalement fait préféré le Go.
Un autre également soucis de Rust, c'est son temps de compilation. On gagne en sécurité mémoire à l'écriture, soit. Mais si on perd un temps fou à compiler. Autant le C++ n'est pas memory safety, mais avec les sanitizers de LLVM de nos jours on arrive à un code en pratique sur (contre une sûreté théorique, même si loin de Ada/SPARK).
Je ne partage pas l'avis pour le parallélisme. Le parallélisme de Rust c'est vraiment limité et on le sent sur les performances, dès qu'on commence à faire des choses un peu bourrines (e.g., calcul matriciel en pure Rust.).
Je veux bien croire que ce soit pratique pour Firefox mais pour du code de calcul non merci Rust. Et qui à binder avec des lib éprouvées en Fortran (mais alors elle est où la safety memoire temps vendu) autant faire des langages réellement utile.
Enfin la syntaxe de Rust, que je trouve à titre personnel, un mélange batard entre du fonctionnel et du LLVM IR. Mais je suis d'acoord avec l'auteur. Pour peu qu'on est un LLM sous la main, Rust devient facilement utilisable. D'où la question de l'intêret de langage ? Un langage fait pour des IA me parait un pari risqué pour le langage lui-même (vu le rejet général de l'IA) et pour certains secteurs industrielles.
Et c'est là que j'explique la faible popularité de Rust. Clairement les offres d'emplois ne se bouscule pas sur Rust. Si je prends le site WelcomeToTheJungle, il y a une 20 d'entreprises qui utilisent Rust contre plus de 330 pour du C++, et encore plus en Python.
Je comprends le besoin de sûreté mémoire, surtout pour des éléments critiques comme des drivers. Par contre, pour du ferroviaire ou de l'aéronautique, bah Ada fait le café non ?
En fait pour moi Rust trouve difficilement une place car d'un coté le C++ est bien implémenter et, autant je suis d'accord avec l'auteur Rust-> C++ c'est ok mais pas l'inverse. De l'autre les industries doivent apprendre une nouvelle stack et avec libs à faire certifier (par exemple FIPS pour le chiffrement), une maigre librairie standard, et le besoin de Cargo (pas forcément un truc acceptable dans des endroits sensibles comme la défense et la sûreté) où le C++ règne fortement et Ada également.
En fait Rust me fait penser à Scilab en enseigne universitaire. De bonnes idées, mais développer par des PhD en info pour des PhD en info. Résultant les enseignants et les étudiants préfèrent Matlab : une syntaxe claire, une document facile à trouver, et on peut réellement se concentrer sur le pourquoi du problème que de ce demander ou mettre cette fichu flèche, crochets ou autre symbole estorérique.
Ce n'est pas un commentaire anti-Rust. J'ai codé en Rust depuis ma dernière intervention dessus. Mais honnêtement dans mon porte-folio de langage (asm, Ada, C et co) je ne vois pas l’intérêt de Rust pour de réels usages industriels. Même en IA Rust ne fait que binder les lib en C ou CUDA. Et vu le temps de compilation Python est largement plus utile niveau rendement et fiabilité (vu l'usage intensif de ces codes, on l'aurait vite vu si il y a avait de graves bugs mémoires).
Si quelqu'un veut en discuter, c'était mes 2 yens.
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?