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 !

L'inclusion de Rust for Linux à la version 6.1 du noyau est désormais en cours comme souhaité par Linus Torvalds
Et va rendre possible le développement de pilotes dans un autre langage que le C

Le , par Patrick Ruiz

26PARTAGES

16  0 
Linus Torvalds l’avait promis lors du dernier Open Source Summit : il pousserait pour l’inclusion de Rust for Linux à la version 6.1 du noyau. La manœuvre est désormais en cours comme le confirme un récent Pull Request. Après 31 ans, un deuxième langage sera donc admis pour le développement du noyau : c’est le Rust. Les débats y relatifs tournent au tour de la possibilité d’une mise au rebut du C au profit du langage Rust compte tenu des avantages qu’il introduit. Petite précision néanmoins : pour le moment, le Rust gagne juste une API officielle pour permettre de développer des modules séparés ou pilotes.


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.


Linus Torvalds fait-il fausse route en ouvrant le développement du noyau Linux au langage Rust ?

Les principaux mainteneurs du noyau Linux ont un âge qui commence par le chiffre 5. Certains se rapprochent même de la soixantaine. Du coup, la communauté du célèbre noyau open source commence à penser au changement de générations. Une nouvelle dont la tranche d’âge se situe dans la trentaine gravit les échelons, mais comme Linus lui-même le souligne : « Il s'avère qu'il est vraiment difficile de trouver des personnes qui sont des mainteneurs » ; un fait lié à ceci que le développement du kernel Linux continue de se faire en C et assembleur – des langages auxquels la vieille génération est plus accoutumée ? C’est une possibilité et elle est susceptible d’expliquer pourquoi 2022 pourrait être l’année du langage Rust au sein du noyau Linux.

Les notes de version de Linux 6.0 rc1 dressent un état des lieux des avancées en ce qui concerne le projet Rust for Linux : un groupe de travail y relatif est en place, un pilote préliminaire pour les supports de stockage NVMe développés avec ledit langage est disponible, ainsi qu’un pilote pour un serveur destiné au protocole de réseau 9P. L’équipe continue néanmoins à faire face des difficultés avec la compilation. En effet, elle se fait avec GCC pour le noyau tandis que Rust l’est encore avec LLVM. Un frontend Rust pour GCC est en cours de gestation mais l’initiative est encore au stade de l’enfance.

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. Linus Torvalds s’est penché il y a peu sur un potentiel problème de sécurité avec les fonctions primitives d'exécution spéculative de la liste liée du noyau écrit en ANSI C. C’est en corrigeant ce problème qu’il s’est rendu compte qu’en C99 l'itérateur passé aux macros de parcours de liste doit être déclaré dans une portée en dehors de la boucle elle-même. C’est de ce constat que venait sa récente décision de faire passer le noyau Linux au C moderne (C11) dont la normalisation est achevée en 2011. C’est le genre de raisons techniques susceptibles de justifier la mise au rebut du langage C au profit du Rust pour le développement du noyau sur le long terme.

La nouvelle de la prochaine inclusion de Rust for Linux à la version 6.1 du noyau arrive dans un contexte où le regard de Linus Torvalds sur le langage Rust a changé. La prise en charge de Rust pour le développement du noyau Linux se poursuit et 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é.

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

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

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

Avatar de Ti-Slackeux
Membre expérimenté https://www.developpez.com
Le 02/04/2024 à 11:35
je me suis arrêté là :
Faut-il opérer le retrait de termes comme master ou slave au motif de ce qu’ils véhiculent des stéréotypes raciaux ?
"Deux choses sont infinies : l'Univers et la bêtise humaine.
Mais, en ce qui concerne l'Univers, je n'en ai pas encore acquis la certitude absolue."
Albert Einstein
19  3 
Avatar de denisys
Membre chevronné https://www.developpez.com
Le 03/09/2024 à 18:59
Remonté contre les habitués du C qui freinent les mises à jour de la base de code du noyau vers Rust
Pour faire une bonne vinaigrette.
Il faut de l’huile et du vinaigre !!!!


A mon point de vue, ce n’est qu’une question de temps et de génération.
Ma génération, qui a étais élevé au bon code en C et C++, vers la fin du siècle dernier (1992).
Les jeunes et futures générations qui intégrerons et compileront plus facilement le code en Rust.

Moi, quand j’ai commencé à développer, le Java Scripte n’existais pas.
Aujourd’hui, tous les jeunes savent coder en Java Scripte.

Haaa !!!
Il ne faut pas oublier, non plus, que le créateur de PHP a conçu ce langage en C, parce que il en avait marre de répéter les mêmes routines en C, pour construire des pages Internet , a l’époque.

C’est une question de temps, uniquement !!!
13  0 
Avatar de OrthodoxWindows
Membre expert https://www.developpez.com
Le 02/04/2024 à 12:03
Citation Envoyé par Ti-Slackeux Voir le message
je me suis arrêté là :

"Deux choses sont infinies : l'Univers et la bêtise humaine.
Mais, en ce qui concerne l'Univers, je n'en ai pas encore acquis la certitude absolue."
Albert Einstein
Je suis d'accord, ce débat est vraiment con. Mais bon, visiblement certains n'ont pas mieux à faire que perdre du temps au lien de réaliser des vrais corrections dans le code.
Cependant, ce genre de polémique stérile est souvent soutenu pas des grosses entreprises ; peut-être faut-il y voir un intérêt pour détourner l'attention de leur méfaits.
Parfois c'est plus direct, c'est le logiciel libre qui est visé (je pense à la polémique sur Stallman).

C'est comme ceux qui sont contre l'utilisation des termes "liste noir/blanche". Alors que culturellement, associer le noir au "mal" ou a la mort n'a rien de raciste, c'est quelque chose de très ancien qui vient du fait que sans lumière, on ne voit rien (on risque donc sa vie). Je ne serai pas surpris que certains peuples en Afrique fassent la même association.
Comparer ça au racisme c'est à peu près la même logique que de dire qu'utiliser la couleur orange pour indiquer un chantier revient à traiter tous les roux de travailleur du BTP
Surtout qu'en plus, aucun homme n'est vraiment "noir" sur Terre, en réalité, il n'y a que des nuances de brun...
11  0 
Avatar de Aspartame
Membre confirmé https://www.developpez.com
Le 02/04/2024 à 13:08
Bonjour

étudiant en master, je m'inquiète sérieusement sur mon diplôme.
13  4 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 02/04/2024 à 20:03
Comme si ne plus utiliser les termes maitres/esclaves allait faire disparaitre l'esclavage ou rendre justice aux victimes présentes, passés, ou futurs.

On peut aller très loin dans la connerie :

Nous tous (ou quasiment) travaillant dans l'informatique sommes des prestataires de services.
service désigne l'action de servir, càd être au service, à la disposition de quelqu'un. Du coup faut-il remettre ce terme en question dans ce contexte, surtout que service vient du latin servitium signifiant état d’esclave, cervitude).
10  1 
Avatar de yannoo95170
Membre régulier https://www.developpez.com
Le 17/10/2022 à 23:49
« Oui, la fenêtre de fusion est de deux semaines, mais c'est surtout pour me laisser le temps d'examiner les choses, pas pour "deux semaines pour mettre en place à la hâte une branche que vous enverrez à Linus le vendredi de la deuxième semaine". L'idée de "faire une nuit blanche pour rendre le papier la veille de la réunion" est quelque chose qui aurait dû disparaître après le lycée. Pas pour le développement de noyaux. La règle est que les choses qui me sont envoyées doivent être prêtes *avant* l'ouverture de la fenêtre de fusion, pas pendant la fenêtre de fusions » a déclaré dimanche Torvalds dans son message.

Pourquoi ne pas mettre en place une fenêtre d'une ou 2 semaines de propositions/analyses de branches **AVANT** l'ouverture de la fenêtre de fusion ?
7  0 
Avatar de petitours
Membre chevronné https://www.developpez.com
Le 02/04/2024 à 17:02
Citation Envoyé par shunesburg69 Voir le message
L'esclavage s'est terminé en France en 1848 et aux USA en 1865, je vois personne de vivant concerné par cette histoire d'esclavage. Pour info, la plupart du temps c'est des militants (noir ou blanc) qui non jamais eux de famille dans l'esclavage et qui oublient que des blancs comme moi ont des ancêtres esclaves et qui s'en foutent de ses débats stériles. Ils feraient mieux de s’inquiéter de la discrimination positive (et autre racisme anti-blanc) qui font du racisme en passant faire l'inverse.
Inde, Chine (les Ouïghours ), Pakistan, et bien d'autres pays. L'esclavage existe bien encore aujourd'hui. Mais une fois de plus le problème est l'esclavage, pas le mot qui le désigne très bien et ça n'a rien à faire dans les discussions sur l'intégration de Rust dans Linux.
7  0 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 03/09/2024 à 20:00
Cette "mégalomanie" existe dans toutes les équipes qui sont formattés à travailler avec un langage informatique. Vous allez dans les banques où on fait du COBOL, les développeurs rabaisseront ceux qui font du Java pour sa syntaxe, ceux qui font du Java rabaisseront ceux qui font du NodeJS/TypeScript pour son manque de typage runtime, ceux qui font du NodeJS/TypeScript rabaisseront ceux qui font du Python pour ses performances, et généralement tout le monde excepté ceux qui font du PHP rabaisseront PHP

Il faut aller au-delà de cela, de cette passion qui nous anime pour un langage informatique, parce que oui nous avons appris, travaillé et en quelque sorte "grandi" avec un certain langage, et on arrive d'ailleurs à reconnaitre les générations grâce à leur formation universitaire Pascal, C++, Java, et plus récemment Python... Et je comprends aussi que certains en ait marre d'apprendre le dernier langage à la mode (je pense personnellement aux langages JVM tels que Scala complètement mort et Kotlin propulsé par IntelliJ+Google suite au procès d'Oracle en ayant fait du Java), ce qui me perturbe c'est que Rust soit considéré comme une mode ou bien les goûts syntaxiques évoqués par certains pour ne pas adopter le Rust. Rust est basé sur le retour d'expérience des langages existants, il existe des raisons pour laquelle Rust inclu/limite des features, comme pourquoi il n'y a pas d'héritage à plusieurs niveaux, pourquoi on continue à utiliser le point-virgule etc (je ne vais pas rentrer dans les détails ici)

Un langage informatique est un outil, ce n'est pas votre enfant ou votre animal de compagnie, l'affect n'a pas lieu d'être. Il faut citer les "vrais" avantages et inconvénients techniques de Rust pour être juste, Rust n'est pas parfait : moins de libraries contrairement à Go qui est supporté par Google (quelqu'un sait s'il existe un driver Sybase en Rust ? ), lent à compiler etc... mais en tant qu'expert seriez-vous capable de me citer des langages libres (compilateur inclu) qui sont à la fois memory-safe, null-safe, thread-safe et qui ne requirent pas une VM que l'on doit installer et qui doit gérer un système de ramasse-miettes ?

Bref, pour en revenir à Linux, bien que le C soit un langage simple et très apprécié, ce dernier ne respecte pas les critères cités au-dessus (je vous invite à regarder les taux des failles de sécurités causés par l'absence du memory-safe ou null-safe), donc qui maintiendra aussi bien le noyau lorsque Linus Torvalds ne sera plus de ce monde ?
7  0 
Avatar de kain_tn
Expert éminent https://www.developpez.com
Le 03/09/2024 à 21:20
Citation Envoyé par Gugelhupf Voir le message
Cette "mégalomanie" existe dans toutes les équipes qui sont formattés à travailler avec un langage informatique.
Je dirais même: Cette "mégalomanie" existe dans toutes les équipes qui sont formatées à travailler avec un seul langage informatique.

Citation Envoyé par Gugelhupf Voir le message
Un langage informatique est un outil, ce n'est pas votre enfant ou votre animal de compagnie, l'affect n'a pas lieu d'être. Il faut citer les "vrais" avantages et inconvénients techniques de Rust pour être juste,
Je ne suis que partiellement d'accord. Je pense personnellement qu'il y a une forme d'art à concevoir et écrire du code. Il y a tout simplement quelque chose de plaisant et d'harmonieux à voir les patterns se former, les couches communiquer. Il y a de la beauté dans certaines expressions épurées.

Et dès le moment où ce n'est plus seulement un outil ou un travail alimentaire, alors les goûts de tous entrent en considération, un peu comme pour la musique et pour tant d'autres sujet ou soudain tout le monde a un avis extrêmement tranché sur ce qui est bien et ce qui ne l'est pas.

J'aime bien la syntaxe de Rust, mais ça doit venir du fait que j'ai pratiqué plusieurs langages assez différents au lieu de me spécialiser dans un seul, et du coup, mes goûts personnels ont évolué avec chaque langage et la philosophie qu'il portait.

J'essaye toujours de choisir mes outils en fonction des avantages qu'ils vont me procurer, mais il y aura toujours certains outils qui me plairont plus que d'autres pour une question de goûts personnels, sur un périmètre donné.

Bien entendu, quand on collabore sur un projet, il faut être capable de faire des compromis, comme sur le style par exemple, pour garder une base de code maintenable et compréhensible.

Je pense que le gros souci, là, c'est qu'il y a deux langages avec une philosophie différente, et sur deux périmètres différents: un est à l'origine de l'ensemble du noyau, l'autre n'est utilisé que pour certains modules (souvent nouveaux), et c'est peut-être vu par certains développeurs comme du code de seconde zone - d'où le manque d'effort et d'engouement de leur part.

Et le gars de redox_os fait un peu le malin dans son tweet et en profite pour se faire de la pub, mais je suis certain que si demain, ses nouveaux modules étaient développés en Lua (pour gagner du temps sur la compilation, puisque tu as évoqué le temps de compilation de Rust) avec le reste en Rust, il y aurait la même animosité de la part d'une partie de ses développeurs, et peut-être une forme de mépris.

Désolé pour le pavé, mais ta réponse m'a inspiré!
7  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 31/08/2024 à 9:02
Il y a bien sur un système de lib standard comme dans tous les langages, la particularité de Rust est qu'il y en a deux :
  • "core" contient juste le minimum pour que le langage fonctionne (type et traits de base).
  • "std" reprend "core et ajoute les fonctionnalités qui dépendent de l'OS (fichier, réseau, allocation mémoire, thread, processus, ...), et quelques types plus avancée (collection, chemins, ...). On reste loin de l'exhaustivité des bibliothèques Java ou Python.


Quand on développe un programme dans des environnements ou l'on a pas accès normal à l'OS (création d'OS, un driver, l'embarqué sans OS), on utilise le mode "nostd" où l'on à plus accès qu'à core. C'est l'équivalent du mode freestanding en C. Le cas du développement de drivers Linux en Rust est un exemple typique de code où l'on utilise le mode nostd.

Ceci dit la grande majorité des programmes Rust finaux utilisent la bibliothèque "std" classique qui donne accès aux fonctionnalités générales de l'OS, en utilisant parfois la libc en interne, vu que c'est le seul moyen stable qu'offrent la plupart des OS pour ce faire.
6  0