C'est désormais officiel : Rust dans le noyau Linux sort du cadre expérimental
Le Rust vient de faire l’objet d’intégration comme partie essentielle du kernel aux côtés du toujours présent langage C

Lors du sommet des responsables de la maintenance du noyau Linux, accessible uniquement sur invitation, les principaux responsables de la maintenance Linux ont décidé que « le consensus parmi les développeurs réunis est que Rust dans le noyau n'est plus expérimental. Il fait désormais partie intégrante du noyau et est là pour rester ». Ce changement vient couronner cinq années de débats houleux sur la question de savoir si ce langage sécurisé au niveau de la gestion des accès mémoire avait sa place aux côtés du C au cœur du système d'exploitation open source le plus largement déployé au monde. De façon plus holistique, c’est la question de savoir si le langage C a besoin d’un remplaçant dans la filière de la programmation système qui refait surface.

C’est une annonce qui ne surprend pas quand prend en compte que Linus Torvalds est d’avis que Rust est une solution d’avenir pour le développement du noyau Linux

La prise en charge de Rust pour le développement du noyau Linux est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

De plus, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.


Brian Kernighan pour sa part critique vivement les performances du langage Rust

« Pensez-vous que Rust ait un quelconque intérêt à remplacer C ? Ou s'agit-il simplement d'un énorme battage médiatique qui finira par s'essouffler ? », a demandé un membre du public. Dans un monde qui évolue depuis des années vers des langages plus sûrs pour la mémoire, la réponse d'un fervent défenseur du langage de programmation C depuis plus d'un demi-siècle promettait d'être tout simplement emblématique. Il s'est montré très très critique.

Brian Kernighan a trouvé son expérience avec Rust « pénible ». Selon lui, les mécanismes imposés par Rust pour garantir la sécurité mémoire sont trop lourds, surtout dans un programme où la gestion de la mémoire n’était pas un problème majeur. Il décrit son unique essai comme « une douleur », et juge l’écosystème du langage — avec ses crates, sa complexité et la lenteur de la compilation — comme « incompréhensiblement vaste et lent ».


« Ohhh, Rust », a déclaré Brian Kernighan, sous les rires du public. « Je n'ai écrit qu'un seul programme en Rust, vous devez donc prendre tout cela avec beaucoup de recul. Et j'ai trouvé cela pénible. Je n'arrivais tout simplement pas à comprendre les mécanismes nécessaires pour assurer la sécurité de la mémoire, dans un programme où la mémoire n'était même pas un problème ! ». Sa plus grande critique semble concerner ses performances de Rust.

« Et le compilateur était lent, le code qui en ressortait était lent... », a-t-il déclaré. « Quand j'ai essayé de comprendre ce qui se passait, le langage avait changé depuis la dernière fois que quelqu'un avait publié une description ! Il m'a donc fallu plusieurs jours pour écrire un programme qui, dans d'autres langages, aurait pris peut-être cinq minutes... »

Le 15 mai 2025, le compte Twitter officiel du projet FFmpeg a publié un message acerbe à l'encontre de Rust qui dit : « [Rust] est tellement bon que l'on peut être payé 20 000 $ pour le rendre aussi rapide que C ». Cette remarque visait l'initiative de Prossimo, qui a proposé une prime de 20 000 $ à quiconque parviendrait à rendre son décodeur AV1, rav1d, aussi rapide que dav1d, une implémentation en C largement reconnue pour sa rapidité.

Cette déclaration a ravivé le débat sur les compromis entre sécurité mémoire, performance et coût dans le développement de systèmes critiques. Il s'agit d'un débat de longue date dans la communauté des développeurs. Certains chérissent les performances brutes, tandis que d'autres préfèrent la sécurité.

Certains intervenants pensent que le choix de Rust est une erreur et que C++ moderne est une meilleure alternative

« Maintenant, "pourquoi pas Rust" ? Tout d'abord, Rust utilise une syntaxe différente (souvent, à mon avis, gratuitement), et non seulement tous les développeurs du noyau devraient se familiariser intimement avec la syntaxe afin d'obtenir le même type de "feeling" que nous avons pour le C, mais convertir du code C en Rust n'est pas quelque chose qui ne peut être fait par les développeurs du noyau qu'au coup par coup, alors qu'avec quelques nettoyages le code C existant peut être compilé en C++.

Cependant, je ne suis pas d'accord avec certaines des conclusions de David. en fait, je crois que David est inutilement pessimiste, du moins en ce qui concerne le C++ moderne.

Notez que personne de sain d'esprit ne s'attend à utiliser toutes les fonctionnalités de C++. Tout comme nous avons le "kernel C" (actuellement un sous-ensemble de C11 avec un avec un ensemble relativement large d'extensions spécifiques au compilateur), nous aurions le "noyau C++", que je suggère d'être un sous-ensemble strictement défini de de C++20, combiné à un ensemble similaire d'extensions de compilateur). Je me rends compte que que la prise en charge du C++20 par les compilateurs est encore très récente pour des raisons évidentes, de sorte qu'au moins une partie de ce qui précède est tournée vers l'avenir », souligne le développeur Linux – Peter anvin.

Jiri Slaby de SUSE Lans s'est prononcé en faveur de cette initiative C++ pour le noyau Linux. David Howells de Red Hat s'est également prononcé en faveur de cette approche.

Source : LWN

Et vous ?

Le langage C a-t-il réellement besoin d'un remplaçant dans la filière de la programmation système ?
Partagez-vous les avis selon lesquels le choix de Rust comme langage de développement du noyau est une erreur ? Voyez-vous le C++ moderne comme meilleure solution aux questions d’évolution du noyau ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents