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 !

La prochaine itération de Rust for Linux pour la version 6.2 du noyau est en cours de gestation et ravive le débat sur la nécessité de la mise au rebut du C
En matière de programmation système

Le , par Patrick Ruiz

20PARTAGES

28  1 
Après 31 ans, un deuxième langage de programmation a été admis pour le développement du noyau Linux : c’est le Rust. Un premier aperçu de Rust for Linux est disponible dans la version 6.1 du noyau. Même si Jonathan Corbet précise « qu’il n’y aurait pas encore assez de Rust dans le noyau pour faire quoi que ce soit d’intéressant », l’inclusion de ce langage vient raviver le débat sur la nécessité de la mise au rebut du langage C au profit du Rust en matière de programmation système. La question divise la communauté des développeurs.

Asahi Linya s’est penchée sur la tâche de développement d’un pilote pour unité de traitement graphique (GPU) pour les Macs M1 et ce, en Rust. Son comparatif entre les langages Rust et C se fait sans langue de bois : « Il n'y a absolument aucune chance que je n'aie pas eu à faire face à la gestion d’accès concurrents, des tentatives d’accès de zones mémoire après libération et toutes sortes d'autres problèmes si j'avais écrit cela en C. Tous les problèmes de concurrence disparaissent avec Rust ! La mémoire est libérée quand elle doit l'être ! Une fois que vous avez appris à faire fonctionner Rust avec vous, j'ai l'impression qu'il vous guide pour écrire du code correct, même au-delà des promesses de sécurité du langage. C'est vraiment magique ! »



« Il y a beaucoup de débats sur l'utilité ou non de Rust dans le noyau... d'après mon expérience, c'est bien plus utile que je ne l'aurais jamais imaginé ! », ajoute-t-elle.



Son retour d’expérience est une espèce de redite d’une compilation de raisons techniques susceptibles de justifier une mise au rebut du langage C au profit du Rust. En effet, 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans (chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE)) sont liées à des tares que traînent le langage C : 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.

De plus, les principaux mainteneurs du noyau Linux sont des habitués du langage C dont l’âge commence par le chiffre 5. Certains se rapprochent même de la soixantaine. Une nouvelle génération de mainteneurs dont la tranche d’âge se situe dans la trentaine gravit les échelons et donc la difficulté de trouver des mainteneurs pour le noyau Linux risque d’aller croissant si son développement se poursuit en langage C. C’est pour autant de raisons que Linus Torvalds a ouvert la porte au développement du noyau en Rust.

Sur la question de l’éventualité d’une mise au rebut du langage C, le créateur du langage C3 liste un ensemble de raisons pour lesquelles les initiatives allant dans ce sens ont de fortes chances d’échouer :

La chaîne d'outils du langage C

Le langage C n'est pas seulement le langage lui-même, mais aussi tous les outils de développement développés pour ce langage. Vous voulez faire une analyse statique de votre code source ? - Il y a beaucoup de gens qui travaillent sur ce sujet pour le C. Des outils pour détecter les fuites de mémoire, les courses de données et autres bogues ? Il y en a beaucoup, même si votre langage est mieux outillé.

Si vous voulez cibler une plateforme obscure, il est probable que vous utilisiez le C. Le statut du C en tant que lingua franca de l'informatique d'aujourd'hui fait qu'il vaut la peine d'écrire des outils pour ce langage, et de nombreux outils sont donc écrits.

Si quelqu'un a mis en place une chaîne d'outils qui fonctionne, pourquoi risquer de changer de langage ? Un "meilleur C" doit apporter beaucoup de productivité supplémentaire pour motiver le temps passé à mettre en place une nouvelle chaîne d'outils. Reste même à savoir si cela est possible.

Les incertitudes d'un nouveau langage

Avant qu'un langage ne soit arrivé à maturité, il est probable qu'il comporte des bogues et qu'il soit modifié de manière significative pour résoudre les problèmes de sémantique du langage. Et le langage est-il même conforme à la publicité ? Il offre peut-être quelque chose comme "des temps de compilation exceptionnels" ou "plus rapide que le C" - mais ces objectifs s'avèrent difficiles à atteindre lorsque le langage ajoute l'ensemble des fonctionnalités.

Et qu'en est-il des mainteneurs ? Bien sûr, un langage open source peut être bifurqué, mais je doute que de nombreuses entreprises soient intéressées par l'utilisation d'un langage qu'elles pourraient être obligées de maintenir plus tard. Parier sur un nouveau langage est un gros risque.

Le fait que le langage pourrait tout simplement ne pas être assez bon

Le langage s'attaque-t-il aux véritables points faibles du C ? Il s'avère que les gens ne sont pas toujours d'accord sur ce que sont les points sensibles du C. L'allocation de mémoire, la gestion des tableaux et des chaînes de caractères sont souvent délicates, mais avec les bonnes bibliothèques et une bonne stratégie mémoire, elles peuvent être minimisées. Le langage ne traite-t-il pas des problèmes dont les utilisateurs avancés ne se soucient pas vraiment ? Si c'est le cas, sa valeur réelle pourrait être beaucoup plus faible que prévu.

Et pire encore, que se passe-t-il si le langage omet des fonctionnalités cruciales qui sont présentes en C ? Des fonctionnalités sur lesquelles les programmeurs avancés du C comptent ? Ce risque est accru si le concepteur du langage n'a pas beaucoup utilisé le C, mais vient du C++, du Java, etc.

L’absence de développeurs expérimentés pour un nouveau langage

Un nouveau langage disposera naturellement d'un groupe beaucoup plus restreint de développeurs expérimentés. Pour toute entreprise de taille moyenne ou grande, c'est un énorme problème. Plus il y a de développeurs disponibles pour une entreprise, mieux elle se porte.

De plus, si l'entreprise a l'expérience du recrutement de développeurs C, elle ne sait pas comment recruter pour ce nouveau langage.

L'ABI C

Si le langage ne peut pas facilement appeler - ou être appelé - par du code C, alors toute personne utilisant le langage devra faire un travail supplémentaire pour faire à peu près tout ce qui est interface avec du code extérieur. C'est potentiellement un énorme inconvénient.

Source : lkml

Et vous ?

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

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

Avatar de smarties
Membre expert https://www.developpez.com
Le 20/11/2022 à 11:20
Quand on voit les tweets, c'est certain que RUST apporte énormément de fiabilité pour de la programmation système.

Je ne suis pas sur de la pertinence d'un transcompilateur car cela peut produire des choses difficilement compréhensibles.

Les bibliothèques système peuvent aussi être écrites en RUST et utilisées pour tout.

Avoir le C et RUST pour le noyau complexifie probablement mais si on peut avoir des éléments de qualité, performants, stables et sécurisés il faut continuer l'intégration progressive de RUST.
5  0 
Avatar de destroyedlolo
Membre actif https://www.developpez.com
Le 16/12/2022 à 15:10
"des mainteneurs pour le noyau Linux risque d’aller croissant si son développement se poursuit en langage C."

Ben voyons
C'est juste le langage le plus utilisé dans les OS (au sens large, démons, DE, ...) inclus, l'embarqué et une bonne partie des applications les plus utilisées.

Alors s'il est difficile de trouver de bons programmeurs C(++), le C a encore de beaux jours devant lui.
"Bon" pas dans le sens "connaisseur du C", mais bon dans le sens "qui maitrise l'algorithmie, ne font pas du code crade, respectent les ressources" : Les enseignements basés autour de langages plus permissifs tel que Python ou Java font que le code qu'ils pondent est au mieux "passable" dès que le langage ne corrige pas toutes leurs lacunes.
3  1 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 18/12/2022 à 10:36
c'est arrivé récemment, donc très peu. tout le code C ne va pas être réécrit en Rust, mais au fur et à mesure du temps ça va augmenter.
2  0 
Avatar de d_d_v
Membre éprouvé https://www.developpez.com
Le 14/12/2023 à 14:15
Citation Envoyé par 23JFK Voir le message
J'ai plutôt l'impression que les dev C n'ont pas envie de réecrire du code qui fonctionne à peu près alors que les dev Rust sont eux très motivés pour réinventer la roue en mieux.
En mieux...ou pas !
2  0 
Avatar de 23JFK
Membre expert https://www.developpez.com
Le 12/12/2022 à 19:21
J'ai plutôt l'impression que les dev C n'ont pas envie de réecrire du code qui fonctionne à peu près alors que les dev Rust sont eux très motivés pour réinventer la roue en mieux.
1  0 
Avatar de smarties
Membre expert https://www.developpez.com
Le 12/12/2022 à 22:04
Citation Envoyé par 23JFK Voir le message
J'ai plutôt l'impression que les dev C n'ont pas envie de réecrire du code qui fonctionne à peu près alors que les dev Rust sont eux très motivés pour réinventer la roue en mieux.
L'intégration RUST avec Cargo est beaucoup plus pratique que le C. Réécrire des bibliothèque permet aussi de se faire la main sur le langage.

Je ne suis pas spécialement pour une réécriture de toutes les bibliothèques mais certaines gagneraient en lisibilité, performance et/ou fiabilité.
1  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 18/12/2022 à 10:38
Presque rien en fait. Les noyau 6.1 (et suivants) ont juste mis a disposition une API Rust pour permettre de commencer le développement de drivers en Rust qui interagissent de manière propre avec le cœur du noyau en restera en C.
Quand des drivers écrits en Rust auront atteint un niveau de qualité suffisamment avancé pour être intégré au projet, ils pourraient le rejoindre, mais ça ne sera probablement pas le cas avant un moment.
1  0 
Avatar de fdecode
Membre régulier https://www.developpez.com
Le 13/12/2023 à 10:28
Je me permets de poster un complément important à ce vieux message que je ne peux plus éditer:
Citation Envoyé par fdecode Voir le message
Les références et références mutables de rust sont des pointeurs (des pointeurs bas-niveau, pas des pointeurs "intelligents" dont l'usage est controlé par la sémantique du langage.
Mais en Rust il est tout à fait possible de travailler sur les pointeurs de manière non-contrôlée, tout simplement en utilisant le mode unsafe { ... }.
C'est découragé, c'est vrai, mais vous pouvez même faire de l'arithmétique de pointeurs en vue d'un adressage non contrôlé de la mémoire.
Même la sacrosainte interdiction de dupliquer les références mutables peut être contournée, comme le montre l'exemple suivant:
Si cette interdiction est sacrosainte, c'est que c'est un comportement indéfini (UB), et il ne faut surtout pas utiliser ce contournement.
Dans cet exemple précis, le compilateur peut faire de l'optimisation de code en utilisant l'information de mutabilité de la référence, ce qui peut induire des résultats imprédictibles si on a transgressé les règles de mutabilité.
Ces optimisations peuvent être comparées à ce que permet le mot clef `restrict` en C.
1  0 
Avatar de frederion
Candidat au Club https://www.developpez.com
Le 18/12/2022 à 10:20
Si j'ai bien compris le nouveau noyau 6.2 est écrit en partie en Rust, mais de combien % ?

Ok j'ai trouvé ma réponse sur GitHub: 0%

Analyse GitHub:
0  0 
Avatar de 23JFK
Membre expert https://www.developpez.com
Le 19/11/2022 à 18:33
Je ne suis pas de ceux qui aiment les projets fait d'un patchwork de langages. Il faudrait plutôt miser sur un transcompiler Rust->C et voir si dans la durée, le Rust peut gagner la partie pour éventuellement abandonner la partie transcompilation.
1  6