Les testeurs inscrits au canal Canary du programme Windows Insiders peuvent récupérer depuis hier soir la préversion 25905. Elle apporte quelques changements mineurs, mais comporte surtout pour la première fois du code Rust dans le noyau Windows.
« Cette version préliminaire est livrée avec une première implémentation de fonctions critiques du noyau en Rust sûr. En particulier, win32kbase_rs.sys contient une nouvelle implémentation de la région GDI. Bien qu'il s'agisse d'un petit essai, nous continuerons à augmenter l'utilisation de Rust dans le noyau », indique ainsi le billet de présentation.
C’est un autre tournant marquant pour le langage créé par Mozilla, après l’arrivée de code Rust dans le noyau Linux.
Microsoft indiquait en 2019 se pencher sur Rust, car le langage avait de nombreuses qualités, dont ses performances et sa sécurité par défaut, avec son typage fort. En mai dernier, en marge de la conférence Build, David Weston, vice-président et directeur de la sécurité de Windows, avait confirmé que le langage arriverait « dans les semaines ou mois » à venir.
Commentaires (25)
#1
Pour les utilisateurs finaux, ça ne change rien en matière d’utilisation?
On ne verra pas + de performances?
#1.1
L’objectif est clairement la sécurité et la stabilité.
#1.2
Tu ne verras pas une différence de performance mais pour MS, sûrement du code plus facile à maintenir et certains risques de sécurité supprimés
#2
Windows est écrit majoritairement en C avec un peu de C++, RUST améliore la sécurité (memory sage) mais je ne pense pas que cela soit plus rapide en pratique.
#2.1
C’est surtout grâce à la mécanique de contrat que tu gagnes beaucoup de temps.
Les contrats sont vérifiés à la compilation. Pour faire la même chose en C/C++, tu as un bloc de code en entête qui va faire les vérifications et qui est exécuté à chaque appel (et je parle même pas des vérifications à la chaine du genre f(i) -> g(i) -> h(i) ou chaque fonction va vérifier que i > 0)
#3
Mozilla qui lutte depuis des années pour survivre et se détacher du financement de Google monétise-t-il RUST pour être tranquille financiérement ou c’est un projet open qui rapporte rien?
#4
Cela sera même a priori plutôt un peu moins rapide, mais sans doute pas sensible par l’utilisateur…
Je persiste à ne pas bien voir d’intérêt de ce langage pour du code OS (driver/noyau) qui bouge assez peu, avec certaines applications qui tirent le max de perf du matériel et seront sensibles à quelques pourcentages de baisse de perf (y’a qu’a voir le foutoir pour activer des mitigations de failles processeur type spectre, avec 3% d’impact démontré sur une application industrielle/embarquée, correspondant à peu près au “niveau d’eau sous la quille” de certaines charges/clients).
Sur ce qui bouge peu, tant que C+outils d’analyse de code modernes permettront d’avoir de meilleures perfs que Rust sans négliger la sécurité ce dernier ne s’imposera pas.
Par contre, pour un Mozilla qui fait de l’application réseau combinant besoin de sécurité avec MAJ fréquente, Rust à du sens.
Pour de l’OS, je pense qu’on a un langage de plus prétendant détrôner le C… C’est loin d’être le 1er!
#5
Non RUST n’est pas monétisé et la gouvernance du projet est ouverte (ça n’est pas Mozilla qui assure tout le développement).
Comme déjà dit, pour des raisons de facilité de maintenance et de sécurité.
RUST est plus safe by design que du C. On parle du kernel et d’un OS, forcément c’est critique.
RUST n’a pas vocation à détrôner le C, mais plutôt à détrôner le C++ au niveau fonctionnel. Pourquoi crois-tu que le kernel Linux accepte RUST et pas C++ ? Concernant les fonctionnalités dites “bas niveau”, RUST peut très bien remplacer le C.
#6
Rust est le langage système moderne, c’est plié, maintenant que les noyaux Linux et Windows commencent à l’intégrer, la dynamique est là.
#7
Niveau fonctionnel je pense que tu vises le côté objet? C’est à mon sens plutôt un problème de plus, car il y en a avant qui ont tenté le coup de faire des OS en C++. Le problème majeur étant qu’avec un langage objet on maîtrise mal ses allocations/utilisation de la mémoire (un new et… vogue la galère, potentiellement différente d’une itération/option à l’autre de la chaîne de compilation utilisée). Ce seul point les rends juste impropre a coder des phases de boot initiales voir tout code devant être de ce point de vue très optimisé. Sauf à vouloir se taper des pb de maintenance, justement, faute de maîtriser assez finement et de manière reproductible ce que son code compilé va donner. Donc quitte à ne pas pouvoir se passer du C, on s’est plutôt passé du C++!
On a beau dire, mais la distance idéale entre un langage “haut niveau” (portable surtout) et la machine, c’est une sacrée contrainte sur laquelle le C fait le job sans jamais poser de pb insoluble.
Mozilla a fait Rust pour satisfaire un besoin d’applicatif évoluant vite et en frontal réseau donc très exposé. Ne jamais oublier le besoin qui a mené à une solution!
#8
Encore une fois, pour du code stable (comme un OS comparé à un applicatif comme un navigateur internet), si C+outils d’analyse (assez longs à passer pour les performants, mais pour du code stable on s’en fout) permettent toujours d’avoir quelques % de mieux niveau perfs que Rust ce dernier ne s’imposera pas. Tout simplement car les produits industriels sont souvent taillés pour autour de 10% de marge niveau charge. Et qu’au bout de 2⁄3 ans, après qq ajouts de features, on tombe sous les 5%.
C’est pourquoi quand j’entends certains dire que Rust a ses chances car il est dans les 3% moins bons que du C, je ne peux m’empêcher de penser que même avec cette différence a priori faible c’est “même pas en rêve”: Ce qui tire les contributions Linux, c’est les industriels du serveur et des télécoms. Et je peux te dire que pour eux chaque % compte!
#8.1
On a vu ces dernières années le désastre à grande échelle de tous ces “codes stables” en C dans les systèmes industriels et objects connectés.
Un “code stable” (qui ne bouge pas) écrit en C c’est du code mort de valeur nulle, et pour des trucs connectés c’est une bombe a retardement de valeur négative, et aujourd’hui c’est simplement illégal.
Sinon ça donne tous ces objets connectés troués de partout et jamais mis à jour (“le code est stable, ça marche”) qui seront tôt ou tard utilisé pour un ddos ou une pénétration. Les outils d’analyse ne seront jamais équivalents à une garantie au niveau du langage.
#9
stable ≠ performant. Pour avoir travaillé dans de l’embarqué très critique, le stable était évidemment prioritaire sur la performance.
Par exemple, disons globalement les fonctionnalités “haut niveau”.
Bah justement, RUST pas mal de problème lié à la mémoire, ça résout donc pas mal de problème de stabilité et maintenance.
#10
Eh bien ça en f(er)ait des milliards de lignes de code “illégales”! Stable ne veut pas dire troué ni n’évoluant plus depuis des mois voir années. Niveau IoT, le pb n’est pas vraiment le C utilisé dans les Linux embarqués omniprésents (et pour longtemps), c’est surtout que les fabricants abandonnent les produits au bout de qq mois.
#11
Certes, observe cependant que les soft avionique de commande de vol (et même missilerie) restent, à ma connaissance, écrites en C qui satisfait donc les les obligations impliquées pour leur certification! Comme quoi du C fiable, on sait très bien faire… Mais côté perf mon propos visait plus l’infra réseau/télécoms, basée sur des plateformes Linux.
Pas trop de lien entre les secondes et les premières, quoique… Les SoC PowerPC utilisés par les premiers ont été fiabilisés pendant plus de 2 décennies par les seconds!
#12
Ce n’est ni un problème de connaissance, de capacité ou de volonté.
Le risque dans le code, est & reste le facteur humain : la machine fait précisément ce qu’on lui demande, même quand on pense lui avoir demandé autre chose que ce qu’elle s’apprête à réaliser.
Le typage fort statique permet d’évaluer statiquement (donc à la compilation) bien plus de choses concernant la déclaration/définition d’objets (des fonctions/méthodes/procédures aux variables) & leur utilisation.
C’est la base de qu’on t’explique en cours de compilation 101 dans ta jeunesse.
Tout ce qui n’est pas statique est par essence dynamique : tout ce que le compilateur ne peut évaluer est une inconnue qui pose un risque à l’exécution.
Le risque des C/C++ est énorme. Beaucoup de fonctions basiques sont extrêmement dangereuses, et nécessite une enveloppe de code vérifiant pas mal de chose pour qu’en définitive on n’appelle/écrive que (dans) des zones mémoire initialisées.
Et je passe sur l’allocation/dés-allocation mémoire manuelle, source de potentielles fuites.
Certains projets développent des suites d’outils ou inhibent statiquement (via macros) des fonctions dangereuses du C pour les réimplémenter avec des vérifications à leurs frontières (entrée/sortie). Ce sont des patchs sur une jambe de bois.
Un typage fort statique dans un langage permettant l’ensemble des possibilité du C est quelque chose d’appelé de leurs vœux par les experts des langages depuis des décennies… et il y en a eu, des tentatives de langages à chaque fois présentés comme révolutionnaires !
Sauf qu’à chaque fois, il manquait des choses, et/ou il y avait d’autres dépendances, et/ou le typage n’était finalement pas bien mieux, et/ou il y avait une machine virtuelle exécutant le code intermédiaire compilée à la volée en JIT, et/ou la taille du code explosait, et/ou les performances étaient ignobles…
Avec Rust, les performances sont très proches de celles du C, et il n’y a pas de glissage sur un point ou un autre en particulier : c’est donc enfin un excellent candidat !
Autre chose, qui n’a pas encore été mentionné : Rust permet aussi, avec la même base de code, de programmer soit en impératif (ce que l’on connait de mieux)… soit en fonctionnel !
La programmation fonctionnelle nécessite de faire fonctionner sa cervelle de manière bien différente, mais peut être aussi une manière de se libérer des tentations de réinvention de roue en décrivant à plus haut niveau ce qui est souhaité, ce qui amène à moins de code de trop bas niveau. Je ne me prononcerai cependant pas sur l’“avenir” que cela peut représenter.
C’est pour moi la première fois qu’un langage rassemble au même endroit un typage fort statique, des caractéristiques proches du C en tous points et la dualité de code impératif/fonctionnel.
Et, comme mentionné auparavant, l’adoption est en marche, ce qui présage non plus uniquement une pépite technique, mais un véritable langage, vivant par son usage (comme une langue ! Eh oui.).
#13
Un garbage collector serait l’avenir? Quelle horreur!
#13.1
Ne fais pas semblant de ne pas comprendre. Rust permet d’éviter d’allouer manuellement de la mémoire, sans garbage collector.
#13.2
Le traumatisme des JVM qui remonte sec !
Non, mais un mécanisme d’allocation qui permet au compilateur de déterminer quand une ressource allouée n’est plus utilisée, voire de recycler des espaces mémoires pour des (dés)allocations successives de même taille.
Un malloc/calloc sans free est quand même le cas d’école de la fuite mémoire !
Il faut sortir de ces manières de faire propices à l’erreur humaine.
Il faut un juste intermédiaire.
https://doc.rust-lang.org/reference/memory-allocation-and-lifetime.html
La partie intéressante est bien évidemment ici le heap (pas d’allocation dynamique dangereuse en stack, le seul risque étant la déprivation de mémoire disponible) : tu remarqueras que Rust gère l’allocation à la place de l’utilisateur, tout en lui garantissant l’adressage constant, comme une allocation dynamique directe (et cette propriété est parfois recherchée dans les programmes qui veulent gérer finement leur mémoire). Rust désalloue l’espace une fois que plus aucune référence n’y est faite.
Et comme Rust est un langage compilé, c’est donc réalisé à la compilation : on a donc une garantie d’absence de fuite de mémoire, sans aucun impact à l’exécution !
Cela a l’air évident, mais cela fait des dizaines d’années qu’aucun langage ne cochait toutes les bonnes cases sur ce qu’il fallait faire pour succéder à C.
Même C++ s’est fourvoyé avec justement de l’espace dynamiquement alloué à l’exécution pour ses objets (+ pelle à étrons derrière)… parce qu’il y était contraint par les faiblesses (ou l’absence de forces, suivant comment on voit les choses) structurelles du C.
#14
Ah bon ? Ce que je connais dans le domaine est en Ada.
#15
Ca a été en effet très utilisé et l’est peut-être encore sur des plateformes très anciennes mais toujours développées. plutôt dans le domaine militaire/ferroviaire (spatial?) d’ailleurs. Mais c’est bien tombé en désuétude et développer-fiabiliser/maintenir tous les outils (chaînes de compilation…) pour les systèmes critiques basés sur des bases processeur récentes (cad moins de 20 ans dans le domaine!) a pu motiver de passer au C. Chez Airbus (des plateformes avioniques post A380 déclinées sur A400M et A350, à minima, a MBDA pour les “usages uniques”) c’est le cas au moins depuis les bases Freescale/NXP PowerQUICC puis QorIQ…
#15.1
C’est du GNAT sur A350.
#16
J’ai bien réfléchi (profondément
) à cette histoire de “Rust”… et j’en ai vraiment marre qu’on tente de nous (re)fourguer du code… tout rouillé !!!
Je veux du code en inox ou en titane, sinon je tape des pieds, je me roule par terre et j’arrête de respirer jusqu’à ce qu’on m’accorde… satisfaction !
=>
=> 
=> patapé, je suis un zombie 
=> 
=>
#17
Donc de l’Ada, GNAT, c’est le compilateur GNU d’Ada.
#18
Je n’aurais pas d’avis définitif, mais à une présentation de ce langage je m’étais quand même dit que certaines acrobaties nécessaires au démarrage d’un processeur/SoC (par exemple quand on n’a pas encore initialisé la DDR et qu’on doit compter sur une sram interne, genre la mémoire de travail ultérieure interne d’un network processor intégré ou un cache plateforme/L3 configurable en sram, le cas rêvé quand prévu par le fondeur… ou quand on n’en a pas, bin être fin sur l’usage dévoyé des caches L1/L2 afin de ne pas déclencher les mécanismes type LRU pour rien avoir qui sorte vers, en l’état du démarrage, le néant), je n’avais aucune idée de comment Rust me permettrait ici de m’en sortir par exemple! L’alternative étant d’y perdre énormément en repoussant beaucoup plus loin ce qui ne peut actuellement se coder qu’en assembleur… ce qui ne fait clairement rêver personne.
Certes, ces niveaux sont désormais de plus en plus faits/fournis par les fondeurs (et là, on ne voit que du C même sur des SoC très récents) et beaucoup de jeunes développeurs même très bas niveau n’ont désormais jamais eu à réellement démarrer un processeur “moderne” de A à Z, ignorant fatalement des cas vécus ou on ne peut vraiment pas se permettre d’avoir un langage qui ne fasse pas exactement ce que l’on veut qu’il fasse (et aussi/surtout, strictement rien d’autre!).