IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

« Le problème vient peut-être de vous », lance Linus Torvalds à un promoteur de Rust dans le noyau Linux,
Linus Torvalds s'immisce dans la rixe qui oppose mainteneurs C et Rust

Le , par Patrick Ruiz

17PARTAGES

5  0 
« Le problème vient peut-être de vous », lance Linus Torvalds à un promoteur de Rust dans le noyau Linux
Linus Torvalds s’immisce dans la rixe qui oppose mainteneurs C et Rust

Après plus de 30 ans, un deuxième langage a fait l’objet d’adoption pour le développement du noyau Linux : Le Rust. L’état des lieux à date fait état de ce que le taux d’adoption de Rust comme langage de programmation pour le noyau Linux reste faible. C’est la raison pour laquelle des promoteurs de Rust comme langage de développement du noyau Linux bousculent en utilisant des méthodes que Linus Torvalds juge malsaines pour la communauté. C’est la raison d’une récente sortie de ce dernier contre Hector Martin qui promeut l’usage de Rust comme langage de développement du noyau Linux.

« Et si vous acceptiez le fait que le problème vient peut-être de vous ? Vous pensez que vous savez mieux [que les autres]. Mais le processus actuel fonctionne. Il a des problèmes, mais les problèmes font partie de la vie. La perfection n’existe pas », lance-t-il à Hector Martin auquel il reproche en particulier sa propension à communiquer sur les réseaux sociaux à propos des écueils en matière d’adoption de Rust dans le noyau Linux plutôt que dans les canaux consacrés par la communauté de développement du kernel.

Le différend est né de l'opposition de Hellwig (mainteneur principal du noyau) à un correctif proposé le mois dernier par Hector Martin et qui devait permettre aux pilotes de périphériques écrits en Rust d'appeler l'API DMA du noyau, principalement basé sur le langage C, qui alloue et mappe des régions de mémoire pour l'accès direct à la mémoire.



Les habitués du langage C n’entendent pas se laisser embarquer dans ce qu’ils appellent la nouvelle religion du Rust

En adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit les 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. Mais les habitués du langage C désapprouvent l'initiative et n’entendent pas se laisser embarquer dans ce qu’ils appellent la nouvelle religion du Rust.

En réponse à Miguel Ojeda, Christoph Hellwig a déclaré : « gardez les wrappers dans votre code au lieu de rendre la vie difficile aux autres », et a poursuivi en affirmant que « les interfaces de l'API DMA devraient rester dans un code C lisible et non dans des bindings bizarres afin qu'il [reste] greppable et maintenable ».

Le souhait de Christoph Hellwig semble être que les pilotes qui ne sont pas écrits en C aient leurs propres liaisons privées avec le code C, et que ces abstractions ne soient pas maintenues séparément, pas même dans l'arbre rust/kernel. Interrogé par Danilo Krummrich, un ingénieur logiciel de Red Hat impliqué dans le projet Rust for Linux, Christoph Hellwig a clairement fait savoir qu'il n'est tout simplement pas intéressé par le code Rust :

« Ne me forcez pas à travailler avec votre langage brillant du jour. La maintenance de projets multilingues est une tâche pénible à laquelle je n'ai aucune envie de m'atteler. Si vous voulez utiliser quelque chose qui n'est pas du C, que ce soit de l'assembleur ou du Rust, vous écrivez dans des interfaces C et vous vous occupez vous-même du décalage d'impédance en ce qui me concerne », a-t-il lancé.

En réponse, Danilo Krummrich a expliqué que Rust for Linux crée un code Rust qui abstrait les API C pour tous les pilotes Rust et qui est maintenu par les développeurs Rust. En d'autres termes, le côté C du noyau reste le même, et les pilotes Rust utilisent des abstractions de ce code C, et ces abstractions sont maintenues par une équipe centralisée dans rust/kernel, ce qui est sans doute mieux que des pilotes ayant leurs propres bindings C individuels.

Mais Christoph Hellwig ne semble pas intéressé par le fait que les abstractions DMA Rust soient maintenues séparément. Christoph Hellwig a expliqué qu'il ne voulait pas d'un autre mainteneur. Il a poursuivi en affirmant que le fait de demander à d'autres de maintenir la couche d'abstraction Rust pour l'allocateur cohérent DMA en tant que composant séparé n'améliore pas les choses et entrave la maintenabilité du noyau Linux :

« Si vous voulez rendre Linux impossible à maintenir à cause d'une base de code interlangage, faites-le dans votre pilote pour que vous ayez à le faire au lieu de répandre ce cancer dans les sous-systèmes centraux. (Où ce cancer est explicitement une base de code interlangage et non Rust lui-même, juste pour échapper à la brigade flameware.)

Chaque bit supplémentaire introduit par un autre langage réduit considérablement la maintenabilité du noyau en tant que projet intégré. La seule raison pour laquelle Linux a réussi à survivre aussi longtemps est qu'il n'a pas de frontières internes, et l'ajout d'un autre langage rompt complètement avec cela.

Vous n'aimerez peut-être pas ma réponse, mais je ferai tout ce qui est en mon pouvoir pour arrêter cela. Ce n'est pas parce que je déteste Rust. Même si ce n'est pas mon langage préféré, c'est certainement l'un des meilleurs nouveaux langages et j'encourage les gens à l'utiliser pour de nouveaux projets là où il convient.

Je ne veux pas qu'il s'approche d'une énorme base de code C que je dois maintenir », a-t-il ajouté.

Source : LKML

Et vous ?

Quels sont les avantages et les inconvénients de Rust par rapport au C pour le code du noyau ?
Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?

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
Vous avez lu gratuitement 8 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Christophe
Responsable Systèmes https://www.developpez.com
Le 11/02/2025 à 19:48
N'y aurait-il pas Ada en 1983 qui était fort novateur à l'époque
Ada n'a pas percé. Peu de gens doivent le connaitre ici.

Mais il n'y a pas forcément de lien entre la popularité de quelque chose et sa valeur pertinente.

L'avenir dira ce qu'il en est pour Rust.
7  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 20/02/2025 à 10:59
Citation Envoyé par d_d_v Voir le message
J'avais écrit sur un autre fil que seuls les incompétents ou très très débutants écrivaient du c++ avec une écriture non "sécurisée" (pas de conteneurs STL, pas de shared pointeurs), et on m'a répondu qu'on ne pouvait pas faire confiance dans le développeur.
Ce qui fait toute la différence entre Rust et C++ au niveau de la sécurisation, c'est qu'elle est opt-in en C++ alors qu'elle est opt-out en Rust.

Même si l'on considérait que la STL et les smart pointers sont memory safe (ce qui n'est pas le cas), il faudrait toujours s'assurer de bien les employer, tout le temps. En C++, quand on sort des clous par erreur, le plus souvent, rien ne nous l'indique. Il ne s'agit pas que d'un problème de débutant, même un développeur expérimenté finit par faire des erreurs, car il n'y a pas de démarcation précise entre ce qui est sûr et ce qui ne l'est pas.

En Rust, par défaut, tout est sécurisé d'un point de vue mémoire. il est peu probable d'écrire unsafe { x.get_unchecked(i) } en toute lettre, sans que l'auteur ne se rendre compte qu'il est en train de faire quelque chose de potentiellement dangereux, et que le relecteur n’identifie immédiatement le risque. Si on travaille avec des gens auquel on ne fait pas assez confiance (qui n'ont probablement pas besoin de code unsafe), il y a moyen de verrouiller son usage dans le projet, ou forcer à documenter chaque utilisation pour expliquer ce qui permet de vérifier que l'utilisation est correcte.
6  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 22/02/2025 à 6:18
Citation Envoyé par djm44 Voir le message
Il me semble qu'il est possible d'écrire un code exact en C ou dans un autre langage.
En théorie, avec des développeur parfait, oui. Mais dans la pratique, même les meilleurs développeurs font des erreurs. L'historique de Linux parle de lui-même : 1020 CVE pour des erreurs de corruption mémoire ont dû être corrigées l'année dernière. Utiliser un langage qui empêche par défaut certains types d'erreurs dont la corruption mémoire est un gros avantage.

Citation Envoyé par djm44 Voir le message
Beaucoup de publicités sont faites sur ce langage Rust auquel je n'adhère pas. Il y a déjà une profusion de langages qui nuit à la simplicité des approches . Chez Mozilla c'est Rust, chez Google c'est Go, chez Apple c'est Swift. Sur le web c'est Java, JavaScript, PHP.
Le terme publicité est très mal adapté. Rust a ses défenseurs qui apprécient ses qualités, mais il n'est pas la propriété d'une société qui aurait besoin qu'il soit largement adopté pour l'écosystème qu'elle distribue comme Apple avec Swift, ou Microsoft avec C#.
Mozilla à participé aux débuts du langage, mais il n'en a jamais particulièrement fait la promotion. Rust était déjà un projet indépendant de la fondation Mozilla lors de sa sortie officielle, il y a dix ans. Ca fait un moment que la contribution de Mozilla à Rust est anecdotique.

Citation Envoyé par djm44 Voir le message
Et finalement le mieux c'est encore le C ou mieux encore le C++ à mon avis vu le nombre de codes existants . Linus Torvalds devrait passer au C++ mais il a une aversion pour ce langage ce qui le pousse vers Rust.
Ce qui fait que le Rust a été choisi là ou d'autres ont été écarté, c'est parce qu'il apportait des garanties de sécurités(contrairement au C++), sans sacrifier les performances et le contrôle du bas niveau (contrairement à la plupart des langages sûrs).
7  1 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 16/02/2025 à 1:07
Citation Envoyé par d_d_v Voir le message
pourquoi ne pas inventer des extensions aux langages existants pour expliciter l'utilisation obligatoire d'un code securisé
Dans le cas du C++, c'est techniquement possible, mais le comité C++ a refusé.
Le 11 septembre 2024, Sean Baxter avait proposé Safe C++.
Le 15 octobre 2024, pour contrer Sean Baxter, Herb Sutter a proposé d'ajouter des principes qui empêchent C++ d'avoir un sous-ensemble à la fois performant et sécurisé : P3466R0 "(Re)affirm design principles for future C++ evolution".
Le 24 octobre 2024, Sean Baxter a argumenté contre ces nouveaux principes ainsi que contre la proposition des "Safety Profiles" de Bjarne Stroustrup : Why Safety Profiles Failed.
En novembre 2024, le comité C++ a voté pour ces nouveaux principes à 29 voix pour, 22 neutres et 2 contre : Trip report: November 2024 ISO C++ standards meeting (Wrocław, Poland).
Le destin du C++ a été scellé.
5  0 
Avatar de
https://www.developpez.com
Le 11/02/2025 à 19:56
Citation Envoyé par chrtophe Voir le message
Mais il n'y a pas forcément de lien entre la popularité de quelque chose et sa valeur pertinente.
Surtout en informatique.
4  1 
Avatar de d_d_v
Membre expérimenté https://www.developpez.com
Le 20/02/2025 à 10:09
Citation Envoyé par fdecode Voir le message
Et qui ferait ça? un débutant en programmation Rust?

En Rust, on évite de programmer en unsafe, quand on est un programmeur confirmé. D'une part, parce qu'on maitrise le paradigme de programmation safe par défaut, d'autre part parce qu'on a appris à minimiser l'usage d'unsafe.
J'avais écrit sur un autre fil que seuls les incompétents ou très très débutants écrivaient du c++ avec une écriture non "sécurisée" (pas de conteneurs STL, pas de shared pointeurs), et on m'a répondu qu'on ne pouvait pas faire confiance dans le développeur. Je ne vois donc pas pourquoi il en serait autrement en rust. Ca fait plus de 20 ans que j'ai travaillé sur plusieurs projets, et à chaque fois, dès que des facilités non recommandées sont offertes dans le langage, il y a toujours des gens qui les utilisent. Ca peut être quelqu'un d'incompétent, ou alors pour corriger un problème en quatrième vitesse en mettant un TODO qui restera ad vitam æternam dans le code, par exemple, ou alors un développeur qui se barre du projet dans une semaine et qui bacle ou sabote le code avant de partir.
Tu peux être sûr et certain, que si une facilité existe, elle sera utilisée, quel que soit le langage.
5  2 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 24/02/2025 à 1:04
Citation Envoyé par djm44 Voir le message
Mais on répète sans cesse cette histoire de sécurité avec Rust alors qu'il est parfaitement possible de faire un code sûr en C et mieux encore en C++.
Pourtant comme je l'ai explicité dans le premier paragraphe du message cité, on voit bien que qu'un nombre très important d'erreurs passe malgré toute la compétence des gens qui développent et relisent le code de Linux (plus d'un millier de CVE l'année dernière pour les erreurs de corruption mémoire).

Citation Envoyé par djm44 Voir le message
Les deux langages ne vont pas évoluer dans le même sens .

C'est pas très clair pour moi ce qui est entendu par là.

D'un point de vue logique, évidement que les langages ont des différences, sinon on se serait contenté d'un seul. Mais il sont interopérables et et gardent l'objectif d'être adapté au bas niveau. Je dirais même au contraire qu'ils se sont plutôt rapprochés avec l'arrivée de Rust for Linux. En effet Rust à priorisé certaines évolutions pour améliorer l'intégration de Rust à Linux.

D'un point de vue technique, le C de base évolue très peu, et absolument pas dans un sens qui pose problème à Rust, au contraire. Quant à Rust, ses évolution sont tout à fait compatibles avec le C et le bas niveau, y compris en ce qui concerne l’interfaçage avec le C.

Citation Envoyé par djm44 Voir le message
Cela demande une double compétence qui va réduire le nombre de développeurs pouvant contribuer au noyau linux. C'est cela le cancer du Rust.
Si Rust a été choisi c'est parce qu'il est attendu qu'à terme, les bénéfices surpassent les problèmes que ça pose.

Vu que le choix d'utiliser d'utiliser Rust se fait par sous-système selon la volonté de leurs mainteneurs, il est prévu que l'impact soit faible pour les mainteneurs existants. La complexité supplémentaire se limitant à la transition entre les sous-systèmes en C et ceux en Rust, travail qui est généralement à la charge du projet Rust for Linux. C'est justement ce qu'indique la réponse de Linus Torvalds : Christoph Hellwig se plaignait des problèmes que Rust allait introduire en terme de maintenance alors que son sous-système n'était absolument pas impacté. C'est le projet Rust for Linux qui a développé l'interface DMA pour Rust et était en charge de la maintenir.
5  2 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 24/02/2025 à 18:36
Citation Envoyé par garvek Voir le message
Pour moi, passer à Rust coûte que coûte pour éviter les soucis de mémoire n'est pas la bonne solution.
J'ai l'impression de devoir répéter tous les dix messages qu'il ne s'agit pas d'imposer Rust a marche forcée quand on a déjà un code C robuste, juste de l'autoriser au cas par cas pour les sous systèmes qui en ressentiraient le besoin, particulièrement les nouveaux drivers. Actuellement il n'est pas utilisé ailleurs que pour de nouveaux drivers. La question de remplacer le C existant n'est pas à l'ordre du jour.

Citation Envoyé par garvek Voir le message
C'est un peu comme passer à Java en se disant que ça supprime les soucis d'allocation mémoire.
La situation est quand même relativement différente de Java dans le sens ou Rust est clairement un langage adapté au bas niveau.

Citation Envoyé par garvek Voir le message
Inversement, à l'heure actuelle les différents programmes que j'ai pu voir en Rust ont une syntaxe vraiment très contraignante et posent de sérieux soucis de lisibilité. De plus la toolchain est encore jeune et évolue fortement d'année en année.
Je ne sais pas quel est ton niveau d'expérience avec Rust, mais je pense que c'est vraiment juste une question d'habitude. Globalement, je trouve le Rust bien plus lisible que le C.

Citation Envoyé par garvek Voir le message
Si l'on combine la technicité très élevée du code noyau, l'aspect très chronophage qui n'est plus compatible avec nos modes de vie actuels et la dette technique qui peut rendre le portage ou la maintenance un calvaire, sincèrement je ne pense pas que pour attirer les nouveaux, en particulier jeunes, est "juste" changer de langage et justifier par un gain de sécurité.
Justement, les retours d'expérience de ceux qui ont développé des quantités de code significatives pour des drivers Rust (en particulier Asahi Lina) est que le langage leur a permis d'être plus productif en perdant moins de temps sur les problèmes technique qui étaient immédiatement identifiés par le compilateur.
5  2 
Avatar de djm44
Membre régulier https://www.developpez.com
Le 25/02/2025 à 0:26
Citation Envoyé par garvek Voir le message


Je ne comprends pas l'analyse qui dit que Rust est choisi pour attirer les jeunes développeurs. Dans le domaine de la Cyber oui c'est abordé, mais sinon les jeunes développeurs sont plutôt formés au Python, et encore au C/C++ ou au Java pour beaucoup d'applications, y compris dans l'embarqué.

Inversement, à l'heure actuelle les différents programmes que j'ai pu voir en Rust ont une syntaxe vraiment très contraignante et posent de sérieux soucis de lisibilité. De plus la toolchain est encore jeune et évolue fortement d'année en année.

Je suis d'accord avec cette remarque. On est loin d'avoir une pénurie de développeurs en C et C++. C'est plutôt du côté de Rust que les développeurs manquent ce qui s'explique facilement. Mais on surestime sans doute l'apport de Rust sur ses facilités de débusquer les erreurs à la compilation alors qu'en C on les observe à l'exécution du code. On peut faire du code sur en C et C++ s'il faut le souligner. La sécurité Rust n'est qu'un détail dans le processus de développement. Et le code de Rust n'est pas très ergonomique c'est une écriture surchargée. Le C++ aussi peut aboutir à une écriture inutilement opaque.
4  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 25/02/2025 à 10:42
Citation Envoyé par garvek Voir le message
Je n'ai pas d'expérience en Rust sur du code bas niveau, je ne l'ai vu que dans le cadre de programmes réseau. Dans ce contexte la performance est secondaire et on empile les crates network/sécu et les fonctions avec des contraintes dans tous les sens ... La perspective de retrouver ça ailleurs me fait un peu peur. Côté syntaxe, je pense qu'il y a beaucoup d'habitude mais de là à dire que c'est plus simple que le C ... (je pense notamment aux séquences avec plein de qualifiers et de | & ...), mais plus lisible que le C++, je suis plutôt d'accord.
Il est vrai que parfois Rust va être plus verbeux que du code C simpliste, mais cette verbosité supplémentaire est souvent ce qui permet d'assurer la sécurité. Un code C aussi sûr serait probablement aussi verbeux et moins lisible.

Par exemple le Rust va obliger à prendre en compte les erreurs via le type Result<Ok,Err>, ce qui peux impliquer des ? pour remonter l'erreur ou des lambda pour les traiter, mais au final c'est bien mieux cadré que le C qui va retourner parfois un null, parfois un code magique, ou un errno qui peuvent être ignorés sans que ça soit manifestement visible.
4  1