L'année 2020 est-elle celle de Rust au sein du noyau Linux ? C'est ce que suggère une sortie de Linus Torvalds
Qui donne des instructions sur l'introduction de son support au système de build
Le 2020-07-19 19:47:37, par Patrick Ruiz, Chroniqueur Actualités
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 2020 pourrait être l’année du langage Rust au sein du noyau Linux.
En effet, au troisième trimestre de l’année précédente, on parlait déjà de la possible entrée au sein du noyau Linux d’un framework pour la mise sur pied de pilotes en langage de programmation Rust. En 2020, la communauté Linux est désormais lancée sur des réflexions en lien à la façon d’intégrer la prise en charge du langage de Mozilla Research au système de build. « Nous devons adopter une approche de prise en charge identique à celle des compilateurs et procéder à la vérification de la disponibilité de divers drapeau de compilation à l’étape de configuration », a précisé Linus. La sortie du créateur du célèbre noyau open source marque en principe son accord avec le principe de la prise en charge de plus en plus importante du langage Rust au sein de Linux. Sur la base de ce seul élément, 2020 pourrait déjà bien être considéré comme l’année du langage Rust au sein du noyau Linux. En effet, ce dernier a, semble-t-il, réussi à convaincre Linus Torvalds là où C++ a échoué.
Le fait avec le langage Rust considéré par des acteurs de la filière comme le futur de la programmation système en lieu et place du langage C est qu’il a obtenu la reconnaissance de « plus aimé » des développeurs habitués de la plateforme de questions-réponses sur des sujets liés à l’informatique – StackOverflow. Au terme de l’édition 2019 de son enquête qui a mobilisé près de 90 000 travailleurs de la filière programmation informatique, le langage a concentré 83,5 % de retours positifs. Ce sont donc près de 75 000 développeurs de ce sondage Stack Overflow qui ont fait savoir qu’ils utilisent le langage Rust et qu’ils vont continuer à en faire usage ; autrement dit, des développeurs qui, après quelques expériences avec le langage, en sont tombés amoureux. C’est une autre enquête cette fois menée par l’équipe de développement du langage et parue au premier trimestre de l’année en cours qui est venue mettre en lumière le fait que le langage reste encore principalement utilisé pour des projets personnels. Raison majeure : manque d’adoption par les entreprises.
Après, la donne est en train de changer puisque le langage commence à bénéficier de soutiens d’acteurs de l’industrie informatique et pas des moindres. À date, il existe une projection du langage Rust pour les API Windows Runtime. C’est une annonce de Microsoft parue au mois de mai dernier. Rust rejoint ainsi C++ avec la bibliothèque Rust/WinRT, ce qui ouvre la possibilité aux développeurs Rust les portes de la mise sur pied de composants et pilotes pour Windows.
C’est un grief qui revient à 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. C’est un défi à relever pour le futur en matière de programmation système et d’après Microsoft, Rust est la meilleure chance de l’industrie informatique pour la mise sur pied d’applications système sécurisées. Ce sont très certainement des développements que la communauté Linux prend en compte au moment de la prise en charge sans cesse revue à la hausse de la prise en charge du langage Rust au sein du noyau Linux. Lorsque l’actuelle équipe de mainteneurs faite de quinquagénaires sera considérée comme les programmeurs COBOL des années 2030, celle des trentenaires sera aux affaires occupée à manipuler un langage sur lequel les experts s’accordent sur ceci qu’il offre de meilleurs gages de sécurité.
Source : lkml
Et vous ?
La difficulté de trouver des mainteneurs est-elle la conséquence de ce que le développement du noyau Linux continue de se faire en C et en assembleur au moment où les développeurs s’intéressent de plus en plus à des langages comme Rust ?
Êtes-vous aussi d’avis que la communauté Linux anticipe non seulement sur les départs en retraite des actuels mainteneurs et sur les qualités que Rust offre en comparaison au langage C ?
Voir aussi :
Rust s'approche de sa première version stable, Mozilla publie une nouvelle préversion de son langage dérivé de C/C++
Linux : un framework pour la mise au point de drivers en langage Rust pourrait faire son entrée dans le noyau de l'OS
L'équipe de npm choisit Rust pour gérer les goulots d'étranglement liés au CPU au détriment de Go, C, C++ et Java, voici les raisons de ce choix
En effet, au troisième trimestre de l’année précédente, on parlait déjà de la possible entrée au sein du noyau Linux d’un framework pour la mise sur pied de pilotes en langage de programmation Rust. En 2020, la communauté Linux est désormais lancée sur des réflexions en lien à la façon d’intégrer la prise en charge du langage de Mozilla Research au système de build. « Nous devons adopter une approche de prise en charge identique à celle des compilateurs et procéder à la vérification de la disponibilité de divers drapeau de compilation à l’étape de configuration », a précisé Linus. La sortie du créateur du célèbre noyau open source marque en principe son accord avec le principe de la prise en charge de plus en plus importante du langage Rust au sein de Linux. Sur la base de ce seul élément, 2020 pourrait déjà bien être considéré comme l’année du langage Rust au sein du noyau Linux. En effet, ce dernier a, semble-t-il, réussi à convaincre Linus Torvalds là où C++ a échoué.
Le fait avec le langage Rust considéré par des acteurs de la filière comme le futur de la programmation système en lieu et place du langage C est qu’il a obtenu la reconnaissance de « plus aimé » des développeurs habitués de la plateforme de questions-réponses sur des sujets liés à l’informatique – StackOverflow. Au terme de l’édition 2019 de son enquête qui a mobilisé près de 90 000 travailleurs de la filière programmation informatique, le langage a concentré 83,5 % de retours positifs. Ce sont donc près de 75 000 développeurs de ce sondage Stack Overflow qui ont fait savoir qu’ils utilisent le langage Rust et qu’ils vont continuer à en faire usage ; autrement dit, des développeurs qui, après quelques expériences avec le langage, en sont tombés amoureux. C’est une autre enquête cette fois menée par l’équipe de développement du langage et parue au premier trimestre de l’année en cours qui est venue mettre en lumière le fait que le langage reste encore principalement utilisé pour des projets personnels. Raison majeure : manque d’adoption par les entreprises.
Après, la donne est en train de changer puisque le langage commence à bénéficier de soutiens d’acteurs de l’industrie informatique et pas des moindres. À date, il existe une projection du langage Rust pour les API Windows Runtime. C’est une annonce de Microsoft parue au mois de mai dernier. Rust rejoint ainsi C++ avec la bibliothèque Rust/WinRT, ce qui ouvre la possibilité aux développeurs Rust les portes de la mise sur pied de composants et pilotes pour Windows.
C’est un grief qui revient à 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. C’est un défi à relever pour le futur en matière de programmation système et d’après Microsoft, Rust est la meilleure chance de l’industrie informatique pour la mise sur pied d’applications système sécurisées. Ce sont très certainement des développements que la communauté Linux prend en compte au moment de la prise en charge sans cesse revue à la hausse de la prise en charge du langage Rust au sein du noyau Linux. Lorsque l’actuelle équipe de mainteneurs faite de quinquagénaires sera considérée comme les programmeurs COBOL des années 2030, celle des trentenaires sera aux affaires occupée à manipuler un langage sur lequel les experts s’accordent sur ceci qu’il offre de meilleurs gages de sécurité.
Source : lkml
Et vous ?
Voir aussi :
-
UtherExpert éminent séniorSi tu choisis tes langages en fonction des trending topics des réseaux sociaux peut-être. Je crois pas que grand monde qui fasse de la vraie programmation système ait sérieusement envisagé Go ou D. Si on prend la peine de se renseigner un minimum sur ces langages, on voit vite qu'ils sont quasi inutilisable sans GC.
Et quitte à ressembler à un disque rayé, on ne demande pas de réécrire l'intégralité du code existant en Rust. Le but est justement de permettre au code Rust de s’intégrer naturellement au code C existant dans le noyau. Ça devrait être utile avant tout pour faire des modules séparés, pas pour refondre le noyau en entier.
Les fonctionnalités "sécurisantes" de C++ sont quand même limitées. Elle ne protègent pas totalement des erreur mémoire, mais surtout, c'est une surcouche à déposer soi-même sur une base non sécurisée. Si on ne la déploie pas bien comme il faut, on peut passer à travers sans s'en rendre compte.
Alors qu'en Rust c'est l'inverse, tout est sécurisé par défaut et si tu veux passer a travers la couche de sécurité il faut le faire explicitement.
Les smart pointers et les divers mécanismes introduits dans les versions modernes de C++, ne suffisent pas à garantir la sécurité mémoire, même si c'est mieux qu'avant. Le C++ de part son historique ne peut techniquement pas offrir le même genre de garantie que Rust sur la mémoire.
Probablement jamais et c'est tant mieux, les avantages de certains langage dans certains contextes sont des inconvénients dans d'autres. Il y a des choses que je ne ferais pas en Javascript, tout comme il y a des chose que je ne ferais pas en Rust (et il n'y a rien que ne ferais en PHP sauf sous la contrainte d'une arme). le 20/07/2020 à 13:07 -
UtherExpert éminent séniorSi c'est ce qui te choques le plus quand tu lis du Rust, je dirais que ça va. Il y a quand même deux trois truc comme les lifetimes explicites qui ont de quoi faire arracher quelques cheveux à ceux qui découvrent le langage.
C'est vrai que d'apprendre un langage supplémentaire peut être un obstacle. Le Rust a quand même un gros avantage quand tu ne le maitrises pas bien, c'est que quand tu fais une erreur d'utilisation, il va le plus souvent juste refuser juste de compiler.
C'est quand même plus sécurisant que des langages comme le C++ qui peuvent facilement introduire des erreurs pernicieuses s'ils sont mal employés.le 20/07/2020 à 1:06 -
abriotdeMembre chevronnéAucun langage n'a eu autant l’approbation de la communauté pour remplacer C. Beaucoup ont dis qu'ils voulaient faire un remplaçant de C. Mais ils ont rarement convaincus et certainement pas pour remplacer C.
* Go à par exemple été conçus pour remplacer C, mais très vite on s'est rendu compte qu'il ne ferait pas l'affaire. Il remporte un certains succès pour remplacer la lourdeur de Java et des problème que fais Oracle.
* D n'a jamais convaincus que quelque barbus. Mais il n'a jamais vraiment révolutionné assez et C++ l'a rattrapé.
Bien d'autres ont voulu allié rapidité de C et simplicité de Python mais c'est techniquement impossible. C'est un peu comme si une voiture de circuit voulait être capable de tracter un poids lourd. En théorie on peu l'imaginer, mais en l'état actuelle des connaissance s'est ne pas être réaliste. On peut surmonter des obstacles mais un par un. Le voyage vers Proxima du Centaure n'est pas pour demain, Mars est un objectif plus réaliste et encore, la Lune représente encore des défis suffisant.
Rust apporte des idées nouvelles que l'on a pas connu depuis l'invention de la programmation Objet (enfin on en a connu mais qui n'ont pas convaincus comme la programation par Aspect). Ou plus récemment depuis LLVM mais cela ne concernait pas le langage lui même mais le compilateur.le 20/07/2020 à 19:05 -
codec_abcMembre confirméFaudrait que tu te renseignes un peu sur le sujet avant de sortir un message ou les 3/4 (si ce n'est plus) est complétement faux.
Rust et Verona n'ont aucun lien (si ce n'est pas qu'ils essayent de résoudre les mêmes problématiques mais différemment). Ils n'utilisent pas la même stack. Verona est implémenté en C++ tandis que Rust est self-hosté. Je ne sais ou tu es aller cherché sort cette histoire de playground.
Non. Rust et Verona sont 2 choses distinctes faites par 2 équipes distinctes. Rien ne les empêche de s'inspirer l'un de l'autre mais vu qu'ils sont dans l'idée différent c'est peu probable que l'un contribue fortement à l'autre (et vice versa).le 20/07/2020 à 15:33 -
UtherExpert éminent séniorSi pour toi "on" c'est les sociétés derrière chaque langage, évidement qu'il vont te préférer leur propre solution mais bon c'est pas ce que j’appellerais une référence.
De plus il faut comparer ce qui est comparable. Les langages que tu cites ne sont pas dans la même catégorie que Rust. Ils sont tous difficilement utilisable pour de la programmation système. Les concurrents de Rust seraient plutôt a chercher du coté de Zig ou Nim.le 21/07/2020 à 10:33 -
walfratMembre émériteQue ce soit clair, je suis bien d'accord avec la remarque de fond, jongler avec beaucoup de langages dans un même projet c'est usant, cependant je pense qu'elle c'est hors-sujet avec l'article, car dans ton genre d'exemple, la variété des langages n'est pas souvent justifiés. Ici on parle bien d'ajouter un langages parce que des gens ont consciencieusement réfléchi et estimes que ce serait bénéfique.
De plus si tu te retrouves à jongler entre 7 langages différents il y a des chances que ce soit par manques d'efforts pour harmoniser un peu tout cela, c'est un problème organisationnel. Avoir plusieurs langages, pourquoi pas mais dans ce cas il faut bien borner ce qu'on fait avec chacun d'entre eux et éviter ceux qui font la même choses.
Bon je dis ça mais je suis en Java, avec du Web de temps en tempsle 22/07/2020 à 10:18 -
GugelhupfModérateurC'est intéressant de voir que des entreprises comme Microsoft ou Linus Torvald (qui ne jure que pas le C
) s'intéressent à Rust. Je comprends la philosophie derrière ce langage qui essaye de faire mieux que le C++ (malgré les nouvelles normes intégrant le concept de smart pointers), par contre je trouve que l'implémentation du concept de lifetime complexifie la lecture du code. le 20/07/2020 à 3:02 -
FreemMembre émériteHeu.... non. Le concept de smart pointer date d'au moins C++98, même s'il y avait des problèmes: std::auto_ptr. Sinon, il y avait aussi quelques articles qui traînaient sur la toile, notamment chez Dr.Dobbs sur le sujet.
Je ne dis pas que C++11 n'a pas amélioré les choses, hein, loin de la... ça a tellement changé le langage que je doute avoir été le seul à l'utiliser depuis avant 2010(ce bon flag --std=c++0x...) le 21/07/2020 à 6:35 -
UtherExpert éminent séniorGo fonctionne très bien, même mieux que Rust en terme d'adoption générale. Mais bien que l'on cite souvent ces deux langages ensemble, ils ont pourtant des visées très différentes. Je pense que le malentendu vient du fait que à la sortie de Go, Google l'a présenté à tort comme un langage système, et qu'a l'époque Rust commençait à faire un peu parler de lui même s'il n'est sorti officiellement que 3 ans plus tard. Google est revenu sur la qualification de langage système pour Go, mais l'idée que c'était 2 langages similaire sortis en même temps est restée.
En fait Go est au C ce que Java a été au C++ : une bonne simplification quitte a abandonner le coté système. Il en résulte un langage très simple a apprendre et relativement efficace. Il remplit parfaitement son rôle dans les domaines ou Java fonctionne bien et il y a été relativement bien adopté.
S'il fallait caser le Rust quelque part, ça serait plutôt du coté du C++, car tout comme lui il a l'intention d’apporter la capacité de faire des abstractions de haut niveau sans renoncer à la programmation système. Il a cependant fait des choix différents dans certains de ses mécanismes, ce qui lui permet notamment de garantir la sécurité mémoire.le 21/07/2020 à 11:23 -
codec_abcMembre confirméC'est uniquement possible sur ceux qui ne sont pas dotés de GC de base (genre C/C++, Rust). Autrement si tu désactives le GC (et ce n'est pas toujours possible) sur les autres langages tu vas justes te retrouver avec des memory leaks de partout.
Faudra que tu m'expliques ce que tu fais dans le développement web alors. Parce que des langages ou tu peux désactiver le GC j'en connais pas des masses qui sont utilisés dans le dev Web.
Le WASM ne peut pas être considéré comme du langage assembleur. Il est similaire sur la forme mais sur le fond il est différent. Il y a certaines restrictions (interdiction des goto arbitraires, vérification des arguments au runtime, etc...) qu'on ne retrouve pas pour de l'assembleur classique. En plus le WASM est jité.
Personne ne te demande de devenir expert dans plein de langages. Tu n'as qu'à choisir un petit nombre (au hasard juste Js) et t'y tenir. Tu n'arriveras pas à me faire croire qu'une bonne maitrise de Js (et potentiellement HTML + CSS mais qui ne sont pas des langages de programmation) ne suffit plus pour trouver un travail. Si c'est le cas c'est soit que tu habites dans un trou pommé ou que tu n'arrives pas à décrocher un poste (et une remise en question serait la bienvenue)
Ce qui est valable pour toi ne l'est pas pour les autre. Je ne m'en fout pas de l'optimal. Je suis content que plein de langages aient été inventés pour éviter de rester coincés avec du Cobol ou de l'asm. Cela vaut aussi pour ceux qui n'existent pas encore mais qui viendront rendre mon travail plus agréable dans le futur. Et ce n'est pas toujours possible ni souhaitable de rajouter des concepts à un langage. Par exemple, c'est impossible de rétro-fiter le système d'ownership de Rust à C++.
Ça sort d’où ce but ? C'est toi qui le défini pour tout le monde ? Ou alors tu parles uniquement pour un but professionnel? Mais alors les gens de l'INRIA qui développe des langages sont payés pour rien ? Mais alors Dennis Ritchie glandait quand il inventait le C ou là c'était justifié ?
Là on sent tout de suite que tu n'a pas testé le langage parce que si ce qui te choques le plus c'est les parenthèses optionnelles autour du if (autrement la syntaxe est très C++) c'est que tu n'as jamais fait de "combat" avec le borrow checker qui est la feature centrale de Rust. Autrement dit, tu formules une critique sans avoir testé ni même lu ce que Rust rend possible.
Les macros de Rust sont hygiéniques en Rust et beaucoup plus puissante qu'en C++. Les 2 ont rien à voir. Ensuite Rust a aussi l'équivalent des constexpr et d'autre features dans cette lignée sont prévu à l'horizon.
Juste non en fait.
Pour un nouveau langage tu as surtout pas pris le temps de tester et ça se voit au contenu de ce que tu post depuis le début. Respectes les autres (et toi par la même occasion) et essayes Rust (ou au moins documentes toi dessus) avant de sortir un florilège de posts vides de sens qui ne sont même pas lié au topic de base (à savoir l'intégration de Rust dans le Kernel Linux)le 22/07/2020 à 15:25