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 !

Linus Torvalds s'exprime à nouveau à propos du débat sur le choix entre C ou Rust pour le développement du noyau Linux
Et laisse entendre que le Rust peut aider à corriger des erreurs commises en C

Le , par Patrick Ruiz

76PARTAGES

25  0 
Linus Torvalds s’exprime à nouveau à propos du débat sur le choix entre C ou Rust pour le développement du noyau Linux
Et laisse entendre que le Rust peut aider à corriger des erreurs commises en C

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. La situation à date est telle que les mainteneurs habitués au langage C refusent de porter le code existant en Rust ou de passer du temps pour aider d’autres contributeurs à le porter en Rust. Linus Torvalds s’est à nouveau exprimé sur ce débat et il en ressort que le langage Rust peut aider à corriger des erreurs commises en langage C.

« Le C est, en fin de compte, un langage très simple. C'est l'une des raisons pour lesquelles j'apprécie le C et pour lesquelles beaucoup de programmeurs C apprécient le C, même si le revers de la médaille est évidemment que, parce qu'il est simple, il est aussi très facile de faire des erreurs », a-t-il déclaré.

En effet, Linus Torvalds est d’avis que le langage Rust est une solution d’avenir pour le développement du noyau. Il considère la prise en charge de Rust pour le développement du noyau Linux 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.


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

Les mainteneurs du noyau réfractaires à la mise à jour des bases de code du noyau Linux vers le langage Rust ont fait savoir quelle est leur position lors d’une présentation des systèmes de fichiers Linux et des besoins en termes de migration des bases de code vers le Rust. Il était question pour ces derniers de créer des passerelles permettant de faciliter l’atteinte de cet objectif. L'un des membres de l'auditoire a exprimé son désaccord en disant : « Vous essayez de convaincre tout le monde de passer à la religion du Rust, mais cela n’arrivera pas. »


Ces derniers multiplient donc des attitudes qui frustrent certains mainteneurs Rust qui choisissent de quitter le navire : « Ce type de traitement est exactement la raison pour laquelle j'ai entamé le projet @redox_os en partant de zéro et en l'écrivant principalement en Rust. Il y a beaucoup de résistance aux changements bénéfiques, même mineurs, dans Linux et les projets connexes. C’est la raison pour laquelle je n'essaie même plus de contribuer au noyau Linux. Il y a des projets pour lesquels vous devrez inévitablement faire passer vos changements devant des mégalomanes pédants et condescendants, et si le noyau Linux n'est pas seulement développé par ce type de personnalité, il est aussi contrôlé par lui de manière écrasante. »

Source : Linus Torvalds

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 ?
Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

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 2 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 eomer212
Membre confirmé https://www.developpez.com
Le 22/10/2024 à 18:50
je me rappelle d'une époque, l'époque "bénie" (j'étais jeune, beau, et je le suis toujours dans ma tête) ou n'y avait pas de coprocesseur, et ou il fallait comprendre comment calculer un sinus à partir d'entiers en assembleur.
bref, on devait ramer comme des malades pour sortir les processeurs et les cartes graphiques vga de leur létargie. il fallait comprendre le materiel, et en particulier le processeur, son fonctionnement et ses limites. qu'on pouvait éventuellement dépasser, par la ruse et l'intelligence.
une des astuces existantes était le déroulé de code.
on déroule des fonctions qui auraient du faire un saut pour boucler, pour éviter le plus possible les branchements qui brisent la prédiction ou le pré chargement de code du processeur.
c'est con, c'est basique, et c'est très, très efficace.
moi je dis ca. mais bon, je peux me tromper, mais je pense que ca doit encore marcher..
en passant, un petit coucou extrêmement révérencieux à Mr Torvald, à qui nous devons tous beaucoup.
11  1 
Avatar de LittleWhite
Responsable 2D/3D/Jeux https://www.developpez.com
Le 22/10/2024 à 18:09
Linus Torvalds est de plus en plus frustré par le matériel bogué et les attaques théoriques du processeur
Moi aussi ! (mais on s'en fout)
9  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 24/10/2024 à 17:34
Citation Envoyé par floyer Voir le message
Dans l’exemple, le replay, c’est gratuit donc c’est toi le produit. Si tu regardes Netflix, il ok, c’est payant mais tu n’as pas de pub. Dans un marché bien fait, tu aurais une offre Premium sans pub.

Bon, le replay gratuit c’est un peu faux… les opérateurs payent les chaînes pour diffuser ce qui est gratuit via la TNT. (Mais en échange, il me semble qu’ils ont droit à une TVA moindre).
Netflix est payant, mais il ne faut pas croire que tu n'es pas aussi un produit. Tes habitudes de visionnage sont judicieusement étudiées.
8  0 
Avatar de JP CASSOU
Membre confirmé https://www.developpez.com
Le 24/10/2024 à 10:53
Ne parlons pas des sites, applis et logiciels bogués et inutilisables

De plus en plus complexes, lourds, lents, bogués et au final inutilisables au quotidien, au point qu'un acte d'achat ou une transaction avec l'internet actuel prend 5x plus de temps qu'une opération à la finalité identique effectuée avec le Minitel des années 1980.

Faudrait peut-être penser à faire un "gel des technologies" et arrêter de concevoir 40.000 frameworks, 2.500 langages de programmation et 38 tonnes de librairies.

Le 64 bits grand public existe depuis le début des années 2000.

Nous avons des applications métier dont on ne se sert pas (ou plus) étant donné leur lenteur et lourdeur au point de rendre les procédures manuelles plus rapides et fiables
7  0 
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 Christophe
Responsable Systèmes https://www.developpez.com
Le 08/02/2025 à 20:03
pourquoi ne pas envisager de développer un nouveau Linux entièrement avec Rust ?
Parce qu'il y a plus de 27,8 millions de lignes de code à refaire (chiffre de 2020).
Et on ne parle que du noyau.
6  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 Uther
Expert éminent sénior https://www.developpez.com
Le 21/09/2024 à 13:44
Comme pour a peu prêt tout ce qu'on dit a propos de Rust, il y a une petite astérisque implicite qui dit indique "* sauf si on utilise du code unsafe".

En l’occurrence, ces fonctions ne sont normalement pas utilisées directement. Elles sont utilisées en interne par les types de base de la bibliothèque qui font des allocations sur le tas comme Vec, Box, Rc, ... A moins de vouloir remplacer ces types par des implémentations maison, on en a pas besoin.
5  0 
Avatar de petitours
Membre émérite https://www.developpez.com
Le 24/10/2024 à 11:21
Citation Envoyé par JP CASSOU Voir le message
Ne parlons pas des sites, applis et logiciels bogués et inutilisables

De plus en plus complexes, lourds, lents, bogués et au final inutilisables au quotidien, au point qu'un acte d'achat ou une transaction avec l'internet actuel prend 5x plus de temps qu'une opération à la finalité identique effectuée avec le Minitel des années 1980.

Faudrait peut-être penser à faire un "gel des technologies" et arrêter de concevoir 40.000 frameworks, 2.500 langages de programmation et 38 tonnes de librairies.

Le 64 bits grand public existe depuis le début des années 2000.

Nous avons des applications métier dont on ne se sert pas (ou plus) étant donné leur lenteur et lourdeur au point de rendre les procédures manuelles plus rapides et fiables
+1
L’évolution des "technos", avec des châteaux de carte compatibilités douteuses et tout cloud servent depuis une bonne 15n d'année uniquement des objectifs de captage client qui ne peut plus regarder un truc sans échapper à la pub, ou faire quelquechose sans laisser un log ou tout simplement plus disposer des données qu'il a envoyé sur une plateforme ou dans le cas des films qu'il a acheté, obligé de rester là, soumis à son prestataire pour continuer à profiter de ce qu'il a déjà acheté et le tout en se faisant assommer de pub ciblées par les données qu'il n'a pas voulu donner même s'il a évidement coché la 5ieme case en partant de la gauche sans quoi le bouton n’apparaissait pas.
Je trouve ça extrêmement frustrant de voir autant de moyens techniques et d'énergie mobilisée pour des services qui assurent de moins en moins la fonctionnalité de base.

Exemple hier soir, et de plus en plus fréquent. Je regarde un film en replay en me payant des tas de pubs (inutiles puisque elles créent en moi un profond rejet) et paf, erreur technique qui s'affiche à 20 min de la fin. On pourrait s'interroger sur la nécessiter d'une liaison internet et d'un serveur surpuissant pour simplement regarder un film mais j'ai surtout mis une bonne demie heure à retrouver là où j'en étais dans le film, car l'avance rapide était non seulement buguée à revenir sans arrêt à 0 mais en plus ça s’arrêtait à chaque période de pub pour me la passer en intégralité. L'appli c’était la pub au service du fournisseur, à la base ça sert à regarder des films, ça ne sait plus faire.

Tu achètes un film, tu ne peux pas le télécharger
Tu achètes de la musique ou le même film, tu as besoin d'une connexion internet et de continuer à payer la plateforme pour voir et écouter ce que tu as déjà acheté
5  0