Depuis sa création par Mozilla en 2015, Rust a parcouru du chemin. Il est maintenant géré par une fondation dédiée, figure régulièrement en tête des langages les plus populaires et Microsoft se demande même s’il pourrait servir à de futurs développements système de Windows.
La grande particularité de Rust, c’est de se situer à mi-chemin entre le C et un langage managé comme le C#. Il a les performances du premier et la protection de la mémoire du second, mettant Rust à l'abri des fuites mémoire et autres dépassements de mémoire tampon.
L’été dernier, lors de la conférence Linux Plumbers 2020, Linus Torvalds avait donné son avis sur l’éventuelle intégration de code Rust dans le kernel Linux, le sujet revenant souvent et de manière plus insistante.
Il n’était pas foncièrement opposé au Rust dans le kernel. Il souhaitait d’ailleurs que le compilateur Rust puisse être détecté par le noyau (via Kconfig) en vue de tester d’éventuelles inclusions de code.
Interrogé récemment par ZDnet en compagnie du développeur Greg Kroah-Hartman, Torvalds a réitéré sa position. La situation a d’ailleurs progressé car un portage de Coreutils en Rust a depuis fait son apparition. Le travail sur ce composant essentiel est réalisé par le Français Sylvestre Ledru, l’un des directeurs de Mozilla et développeur de Debian.
Torvalds se dit en attente et continue d’observer l’évolution. Ledru lui-même estime que le portage est fonctionnel, mais pas encore de qualité nécessaire pour la production. L’objectif serait quand même un remplacement de l’actuel Coreutils par sa version Rust.
Mais Torvalds pense que les pilotes sont un bien meilleur choix pour tester l’intégration de code Rust dans le noyau. Kroah-Hartman abonde : « les pilotes sont probablement le premier choix pour une tentative comme celle-là, puisqu’ils sont « les dernières feuilles » sur l’arbre des dépendances dans les sources du noyau. Ils dépendent de fonctionnalités centrales du noyau, mais rien ne dépend d’eux ».
Tous deux s’accordent sur l’extrême prudence qu’il faudra montrer, et l’attention qui sera portée aux premiers essais. Tout se jouera dans les interactions entre le nouveau code en Rust et l’architecture du noyau en C.
Commentaires (22)
#1
Petite précision : 2015 c’est la 1ère release stable, Mozilla a commencé à “sponsoriser” le projet en 2009.
#2
Le problème avec Rust dans Linux est qu’il ne supporte pas autant d’architectures que Linux.
#3
J’ai des réserves à ce sujet pour 2 raisons :
Le C est un langage relativement proche de l’assembleur ce qui lui confère un grand contrôle de la mémoire, évidemment pour le meilleur et pour le pire. Pas sûr que Rust ait cette même flexibilité. Comme indiqué dans la news, les pilotes seront probablement le meilleur endroit pour tester mais avec une grande vigilance sur la faisabilité.
C est l’écosystème de référence pour les API système et les premiers compilateurs pour une nouvelle architecture sont quasi systématiquement en C. Casser cet état de fait n’est pas forcément souhaitable notamment pour les portages.
#3.1
Rust est très flexible, même sans faire directement de l’assembleur il permet d’avoir tout le contrôle que l’on souhaite sur la mémoire. Par contre si tu veux faire n’importe quoi avec la mémoire, tu dois dire au compilateur que ton bout de code est unsafe, et que c’est toi qui gère.
Il n’est évidemment pas question de casser ça, aujourd’hui les premières expérimentations de Rust sur le noyau Linux ont été faites sur les drivers, on n’est encore loin des appels système.
#4
Il y a quand même un OS écrit en Rust, je pense pas que Rust soit limitant à ce niveau là. Mais Linux est employé dans beaucoup d’environnements, on peut pas faire n’importe quoi, n’importe comment.
https://www.redox-os.org/fr/
#4.1
Où est l’ISO ? xD
#4.2
J’ai mis 2 minutes à trouver :
#4.3
Le site redox-os.org est down, et je ne vois pas comment installer les fichier du GitLab en passant par Etcher par exemple
#5
Je t’invite à consulter la doc de rust à ce sujet. La doc est très digeste et tu trouveras très rapidement de quoi te rassurer et constater que tu as même plus de contrôle car la doc t’explique clairement les avantages et inconvénients de l’utilisation de la pile ou du tas.
#6
Maintenant, si a des endroits ou tu dois gérer il faut tout mettre en unsafe, quel est l’intérêt d’un language un poil moins performant, avec un formalisme qui va être plus des emmerdements à contourner qu’un apport?
Par contre, pour de l’applicatif qui n’a pas ces besoins un langage qui rends difficile les fautes de programmation (restera celles possibles dans la logique du programmeur, mais celles là ne seront jamais réglées par un language), particulièrement quand il est volumineux et en frontal réseau avec des besoins de sécurité élevés. Pourquoi pas: En plein dans le cas d’usage de Mozilla, au passage.
Pour du démarrage, kernel et même drivers, je pense que le C va voir passer un challenger de plus. Ca ne sera pas le 1er!
#6.1
L’intérêt est de pouvoir cloisonner les parties à risques. Tu peux alors consacrer plus d’attention sur ces parties-là pour t’assurer au maximum de présenter une API safe autour. Le code qui va utiliser ta partie unsafe ne le fera qua via une API safe. Tu as une étendue beaucoup moins grande de code à réévaluer lorsqu’un bogue sur la gestion mémoire est remonté.
Pour ce qui est des performances, on ne sait pas dire que le language est un poil moins performant. La variabilité de performance induite par la manière d’implémenter l’algorithme est tellement grande que ça n’a pas de sens de vouloir comparer les performance de ces deux langages, surtout à partir du moment où le Rust n’impose rien au niveau runtime (contrairement aux langages managés, où là tu pourrais parler du coût de performance inhérent au langage).
#6.2
Qu’est-ce qui est préférable ? Que tout soit unsafe par défaut ou simplement des parties bien identifiées ?
#7
:/
#7.1
J’avais lu que c’est impossible, car le problème vient du langage lui-même, qu’à moins de tout casser c’est pas trop possible. Après j’en sais pas plus.
#8
C’est pas un problème à régler, c’est le principe même du langage. C’est juste une philosophie très différente des langages de programmation modernes. Faut pas oublier que ça date des années 70 le bazar
#8.1
Je suis aussi vieux que le C, donc je connais bien les limitations du langage. Et certaines ont été surmontées.
Un exemple qui parlera a beaucoup: les inclusions des entêtes (*.h).
Au début du C, chacun faisait un peu ce qu’il voulait dans ses entêtes. Résultat: un enfer de déclaration manquante, ou de multi-déclaration, voir même d’inclusions récursives. :/
Maintenant c’est assez discipliné. Tout le monde structure son header avec “#ifndef, #define, #endif”.
#8.2
Heu, c’est une évolution du langage ça ? C’est plus un workaround qu’autre chose.
Parce qu’alors, on peut aussi dire qu’on a résolu les problème de fuite mémoire ou de double free. Maintenant, on est disciplinés, on fait gaffe à bien associer un et un seul free à chaque malloc sur l’ensemble des fils de code possibles que peut suivre le programme…
#9
Quel problème?
#10
C’est une bonne pratique qui est devenue discipline de codage, voire même qui est implémentée dans les éditeurs de code. Au final, ca résout un problème inhérent au langage C au point que plus personne n’en parle.
On attend toujours l’équivalent pour l’allocation/cast de zone mémoire. Du moins, je ne connais pas de règle universellement appliquée aujourd’hui qui a fait disparaître le problème.
#11
Le language C lui-même est obsolète et inadapté pour écrire du code moderne, même pour le noyau ou de l’embarqué.
Le problème pour bouger du C, c’est la compatibilité inter-language.
Le C est le plus petit dénominateur commun, presque tous les “grands” languages ont des manières de générer des bindings avec du C (Java avec JNI, Python avec CPython),
voire peuvent directement appeler des fonctions C (Go, Rust) ou sont rétrocompatibles avec le C (C++, Objective C).
Mais il est bien plus complexe pour ces languages d’interopérer entre eux. Tant qu’un vainqueur n’aura pas émergé pour remplacer C comme language bas-niveau, avec un écosystème de générateurs de bindings pour les autres principaux languages, on restera sur une base C.
Honnêtement je pense que Rust est le mieux placé pour ça, il coche toutes les cases.
Go est le principal compétiteur, mais de plus haut niveau avec son garbage collector, trop pour de l’embarqué ou du code noyau.
#12
Certes, mais cette inter-compatibilité ne nécessite pas d’utiliser du C.
Un exemple concret : il y a deux semaines à peine j’avais besoin d’appeler une librairie Go depuis du code C#. Les deux ont des bindings compatibles avec C, et du coup compatible entre eux, et j’ai pu utiliser ces bindings pour faire communiquer les deux librairies sans la moindre ligne de C.
En d’autres termes, utiliser une ABI compatible avec C n’implique pas forcément d’utiliser du C derrière.
#13
Le pb, c’est de de devoir mixer les deux AMHA. Puis c’est pas comme si les outils d’analyse ne progressaient pas, de plus en plus intégrés aux chaînes de compilation.