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. sont dans la filière de la programmation système. Ici, on est dans les méandres du fonctionnement des systèmes informatiques ; on parle de code avec lequel l’utilisateur n’interagit, car distinct de celui de la couche dite applicative. Le développement du système UNIX a débuté en 1969 et son code a fait l’objet de réécriture en langage C en 1972. En 1985, c’était la sortie de Windows 1.0. Même si le code source du système d’exploitation de la firme de Redmond est fermé, l’entreprise elle-même a indiqué que le noyau du système d’exploitation est principalement écrit en C. C’est pareil pour Linux dont la plus grosse part de la base de code est écrite en C. Mais le langage C ne se limite pas aux projets qui ont débuté il y a des dizaines d’années, ce, lorsqu’il n’y avait pas encore toute la panoplie de langages de programmation qu’on connaît. En fait, en matière de programmation système, le langage C peut désormais être considéré comme l’actuelle norme. « Le langage C est le nouvel assembleur », déclare Josh Triplett d’Intel.
Ce qu’il faut dire c’est que le C s’est imposé aux travailleurs de la filière programmation système pour plusieurs raisons. Lors du récent Open Source Technology Summit, l’ingénieur d’Intel est revenu sur certaines. Primo, il y a qu’en tant que langage évolué, le C permet aux développeurs de gagner en matière d’utilisabilité et de productivité ; c’est moins de lignes du code pour accomplir les mêmes tâches en comparaison à l’assembleur. C’est aussi un niveau de performance qui proche de celui de l’assembleur Deuxio, il y a que le passage au C n’induit pas de pertes en termes de possibilités que l’assembleur offre.
Il y a seulement que lors du dernier Linux Security Summit, des chercheurs en sécurité ont, à côté d’autres, mis le doigt sur l’une des plus grosses tares que le langage C traîne : 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. Lors de sa sortie à l’Open Source Technology Summit, l’ingénieur d’Intel est revenu sur ce détail en ajoutant que « les développeurs ont besoin d’un langage évolué qui apporte réponse aux problèmes qui ne peuvent être résolus en C et qui introduit des fonctionnalités intéressantes. »
Ceux qui programment en langage C savent que le développeur s’occupe à la main des aspects de gestion de la mémoire ; il fait le nécessaire au sein du code pour que réserver des portions de mémoire et les libérer lorsque nécessaire. Ce détail divise les observateurs quant à savoir si l’on doit laisser la main au développeur ou s’appuyer sur des fonctionnalités du langage pour automatiser la gestion de la mémoire. En tout cas, Josh Triplett cite la gestion automatique de la mémoire comme l’un des avantages que le langage Rust offre en comparaison au C.
Le développement de l’ingénieur d’Intel laisse également filtrer que le Rust offre plus d’avantages que le langage C pour ce qui est de l’utilisabilité et de la productivité. « Tout langage qui veut être meilleur que C doit offrir bien plus qu'une simple protection contre les dépassements de mémoire tampon s'il veut se positionner comme une alternative convaincante. Les gens se soucient plus de l'utilisabilité et de la productivité. Ils sont plus intéressés par la possibilité d'accomplir d'importantes tâches avec peu de lignes de code. Il y a aussi que convivialité et productivité vont de pair avec la sécurité. Moins vous avez besoin d'écrire de code pour accomplir quelque chose, moins vous avez de chance d'introduire des bogues de sécurité ou autres », explique-t-il. Ce serait l’une des raisons qui a intéressé Mozilla et a amené la Fondation à arrimer le projet de navigateur Quantum à Rust. Les retours d’expérience font état d’un impact positif sur la réduction du nombre de lignes de code et des failles de sécurité dues à la gestion de la mémoire.
Josh Triplett reconnaît néanmoins que sur le terrain de la parité en termes de possibilités offertes, il y a encore un gap à combler avec le langage C. C’est la raison pour laquelle il a, en 2015, introduit un Request For Comment pour le support natif des unions compatibles C en Rust. L’ingénieur d’Intel a également eu à contribuer pour la prise en charge des structures et des unions sans nom sous Rust. La programmation système implique d’effectuer des manipulations de bas niveau en assembleur. En Rust, l’on s’appuie sur la macro asm, mais à date, elle n’est présente que dans le compilateur en nightly et n’est pas encore stable. En collaboration avec d’autres développeurs Rust, l’ingénieur d’Intel travaille à la mise sur pied d’une syntaxe plus robuste d’introduction de code assembleur au Rust. Plusieurs processeurs s’appuient désormais sur le Brain Floating-Point Format (bfloatf16) – un format de données dont on fait usage en apprentissage profond. À date, le Rust ne dispose pas de support pour ce dernier ; un autre axe sur lequel Triplett est engagé.
Tous ces aspects feront l’objet de développement au sein d’un groupe dont il a annoncé la création. En collaboration avec la communauté Rust et d’autres développeurs chez Intel, l’initiative vise à développer les spécifications pour les fonctionnalités qui manquent pour faire du Rust le langage qui devrait envoyer le C aux oubliettes.
Source : Vidéo
Et vous ?
Qu’en pensez-vous ? 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 : un « Pony » peut cacher un langage, l'outil adéquat, d'avis d'utilisateurs, pour le développement d'applications concurrentes C2 : un langage qui se présente comme une évolution de C, plus rapide, sans fichiers d'en-tête, avec système de build intégré et d'autres changements Quel avenir pour le langage C ? Un développeur expérimenté fait ses adieux au langage et livre ses inquiétudes quant à son avenir 
Envoyé par Patrick Ruiz
