Discussion :

[Patrick Ruiz]

« Rust est le futur de la programmation système et C le nouvel assembleur », d’après un ingénieur d’Intel
Qui explique pourquoi il est pertinent de passer à Rust


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

[Neckara]

Ouais, enfin des "futurs de la programmation", on en a 10 par ans...

[Uther]

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.

Attention Josh Triplett a bien expliqué que cette phrase n'avait pas pour vocation a servir de titre. C'est une personne qui a écrit un rapport sur la présentation qui l'a utilisé ainsi. Josh Triplett a bien précisé qu'il n'aurait pas choisi ce terme car sa présentation se voulait nuancé et pas en opposition frontale au C.

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.

Cette présentation des choses est un peu trompeuse : l'avantage de Rust pour la programmation système par rapport à la plupart des autres langages modernes, c'est justement qu'il n'a pas une gestion automatique de la mémoire. Comme en C il faut savoir quand on alloue la mémoire et de quelle manière. Il a plutôt une assistance à la gestion mémoire qui empêche les mauvaises utilisation.

Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?

Je pense que oui, les avantages de Rust sur le C sont indéniables. Par contre, comme c'est expliqué dans cette présentation, le C garde des avantages dans certains contexte, en grande partie à cause de sa place centrale actuelle dans la programmation système.
Ça n'est pas demain que Rust va remplacer 100% du code C, mais c'est quelque-chose qui gagnerait clairement à se faire sur la durée.

Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?

Cette question n'a pas de sens. Bien sur qu'avec des développeurs parfait, ont pourrait tout faire en C, en assembleur, voire directement en langage machine, ...
Dans la pratique un langage adapté permet d'être plus productif et plus fiable.

Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ?

A moyen terme oui, ça semble une bonne idée. C'est le genre de projet ou Rust à toute sa place. A court terme, probablement pas, c'est le genre de transition dans laquelle on ne se lance pas à la légère.

Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

C'est des cas a étudier au cas par cas, comme expliqué dans la présentation, il reste des cas ou Rust n'est pas encore totalement adapté.
Mais Rust est en effet utilisable, dès aujourd'hui dans la grande majorité des projet de prog système où l'on aurait envisagé que le C ou le C++ il y a quelques années.

Ouais, enfin des "futurs de la programmation", on en a 10 par ans...

C'est pas faux, mais il faut reconnaitre que Rust a fait bouger les lignes dans la programmation système qui étaient complètement figées depuis des années.

[Neckara]

C'est pas faux, mais il faut reconnaitre que Rust a fait bouger les lignes dans la programmation système qui étaient complètement figées depuis des années.

Je veux bien te croire, et même croire que Rust soit plus crédible que 90% des nouveaux langages qu'on nous présente.

C'est jusque qu'on nous dit sans cesse "il faut abandonner C, il faut passer à Go", "il faut abandonner C, il faut passer à D", "il faut abandonner C, il faut passer à Rust", "il faut abandonner C, il faut passer à Objective C", ...
Alors qu'en réalité, c'est malheureusement surtout le JavaScript qui est en train de gagner.

Je n'ai rien contre un successeur du C, mais tout le monde veut être son successeur, or, on ne pourra pas en avoir 50 successeurs, et on ne va pas changer de langage tous les mois, au gré des modes.

[Jamatronic]

C'est jusque qu'on nous dit sans cesse "il faut abandonner C, il faut passer à Go", "il faut abandonner C, il faut passer à D", "il faut abandonner C, il faut passer à Rust", "il faut abandonner C, il faut passer à Objective C", ...

Tout ceci est plutôt signe qu'il ne vaut mieux pas abandonner C, en fait.

[Mimoza]

Je ne sais pas si c'est un avis partagé, mais Go a eu son moment de gloire avec Docker, mais Rust a l'air de convaincre bien plus de monde …
Pour ma part si je devais investir sur un langage Rust me parait un meilleur choix.
Seul l'avenir nous le dira.

[Guntha]

Tout ceci est plutôt signe qu'il ne vaut mieux pas abandonner C, en fait.

Pour moi, c'est plutôt un signe qu'aucun des créateurs de ces langages n'a compris pourquoi C était encore utilisé. J'ai l'impression qu'ils ont été faits pour limiter l'impact qu'un développeur pas soigneux peut avoir sur le fonctionnement d'un programme, sans considération pour les performances, sans même d'objectif sur le type de projet sur lequel ils aimeraient le voir utilisé, dans un monde où la Programmation Orientée Objet a été longtemps présentée comme la seule "bonne" manière de programmer.

L'avantage des créateurs de Rust, c'est qu'ils utilisent leur langage sur un vrai projet, et un gros!

[23JFK]

Présenter un langage dont la syntaxe n'est pas encore stabilisée et auquel il manque de fonctions de substitutions comme un successeur du C est ... Odacieux...

[Neckara]

Je ne sais pas si c'est un avis partagé, mais Go a eu son moment de gloire avec Docker, mais Rust a l'air de convaincre bien plus de monde …
Pour ma part si je devais investir sur un langage Rust me parait un meilleur choix.
Seul l'avenir nous le dira.

C'est justement cela le problème.

Imagine à l'époque, on te dit "Go c'est l'avenir", tu les écoutes et passe du C au Go. Quelques années plus tard, l'effet de mode disparaît, et on te dit "Rust, c'est l'avenir".
Qu'est-ce que tu fais maintenant ? Tu continue en Go, augmentant ta dette technique le jour où il te faudra changer de langage ? Tu réécris ton code en Rust, te faisant perdre des années de développement ? Tu passes du temps à faire un binding, avec le risque de te retrouver avec un monstre de Frankenstein composé de patchwork en plusieurs langages ?

[perenono]

Ouais, enfin des "futurs de la programmation", on en a 10 par ans...

Tout à fait d'accord, cela fait 20 ans que l'on nous parle d'alternative que ce soit à l'assembleur à c ou a java. Résultat sont toujours là et bien là avec de nombreux autres langages comateux!

Par contre, il serait bon de retoucher l'article et ne pas laisser qu'Unix est un langage!!!

[Pyramidev]

Imagine à l'époque, on te dit "Go c'est l'avenir", tu les écoutes et passe du C au Go. Quelques années plus tard, l'effet de mode disparaît, et on te dit "Rust, c'est l'avenir".
Qu'est-ce que tu fais maintenant ? Tu continue en Go, augmentant ta dette technique le jour où il te faudra changer de langage ? Tu réécris ton code en Rust, te faisant perdre des années de développement ? Tu passes du temps à faire un binding, avec le risque de te retrouver avec un monstre de Frankenstein composé de patchwork en plusieurs langages ?

Il faut distinguer le cas où on a besoin de performances vraiment bonnes du cas où on n'en a pas besoin.
Dans le premier cas, on exclut tout de suite les langages qui imposent un ramasse-miettes, dont Go. Il reste alors peu de choix. Aujourd'hui, C++ domine, mais possède plein de défauts. Rust est un bon candidat.
Dans le deuxième cas, on n'a pas envie de passer du temps à gérer rigoureusement la mémoire. Dans ce cas d'utilisation, je ne sais pas quel sera le langage du futur (Julia ?), mais ce sera un langage avec un ramasse-miettes, donc pas Rust.

[frfancha]

Alors qu'en réalité, c'est malheureusement surtout le JavaScript qui est en train de gagner.

Aucun rapport:

-Javascript ne gagne rien du tout en programmation système.

-Javascript, dans son domaine, est un excellent langage

[Aiekick]

c'est vrai que la gestion mémoire est la 1ere source de bug critique en c et c++. mais j'aimerais bien passer a rust, pourquoi pas. mais 99.9% des lib utiles sont en c ou c++

[Uther]

C'est jusque qu'on nous dit sans cesse "il faut abandonner C, il faut passer à Go", "il faut abandonner C, il faut passer à D", "il faut abandonner C, il faut passer à Rust", "il faut abandonner C, il faut passer à Objective C", ...

C'est pas du tout l'impression que j'ai, par contre chaque fois que je vois une présentions honnête d'un langage qui ne prétend rien de plus que pouvoir fournir une alternative, je vois des défenseurs du C qui se lamentent comme si on allait exiger de remplacer l'intégralité du code C existant, sous 15 jours, pour les mettre définitivement au chômage.

Je vois pas grand monde de sérieux dans l'industrie qui dit, "il faut abandonner C, il faut passer à X", du moins pas de manière absolue, pas sans une étude du contexte qui indique que le changement est vraiment utile et pas sans un plan de transition bien pensé.

Je n'ai rien contre un successeur du C, mais tout le monde veut être son successeur, or, on ne pourra pas en avoir 50 successeurs, et on ne va pas changer de langage tous les mois, au gré des modes.

C'est évident qu'on ne va pas changer de langage tous les mois, mais j'ai vraiment l’impression que ce genre de discours sert surtout d'excuse à beaucoup de gens pour ne pas prendre la peine de regarder plus loin que le bout de leur nez, ce qui est quand même fort dommage.

Je ne sais pas si c'est un avis partagé, mais Go a eu son moment de gloire avec Docker, mais Rust a l'air de convaincre bien plus de monde …
Pour ma part si je devais investir sur un langage Rust me parait un meilleur choix.
Seul l'avenir nous le dira.

C'est surtout que c'est une très mauvaise approche du problème. Il n' y a pas besoin de chercher un langage vainqueur qui battrait tous les autres. Le problème, c'est "Est-ce que le langage est efficace à remplir sa mission par rapport aux alternatives existantes ?".

Il n'y a pas besoin de trouver un gagnant entre Rust et Go, vu que même si on peut leur trouver des points communs, ils ne recouvrent pas exactement les mêmes besoins. Go n'étant pas du tout un langage système (contrairement a ce qui a été annoncé au début), il n'est pas du tout adapté à faire des application embarquée, temps réel, des drivers, un OS, ... Par contre sa bibliothèque et sa facilité d'utilisation en font un très bon candidat pour un serveur d'applications Web.

Pour moi, c'est plutôt un signe qu'aucun des créateurs de ces langages n'a compris pourquoi C était encore utilisé.

Je pense qu'il l'ont très bien compris, c'est juste qu'il ne visaient pas ce marché. D, Go, ... visaient plus les développeurs d'application de haut niveau, ils n'ont pas remplacé le C car ils n'ont jamais réellement essayé de le faire.

Présenter un langage dont la syntaxe n'est pas encore stabilisée et auquel il manque de fonctions de substitutions comme un successeur du C est ... Odacieux...

La syntaxe de Rust est stabilisée depuis la version 1.0 (2015). Je suis curieux de savoir ce que tu appelle fonctions de substitution.

Imagine à l'époque, on te dit "Go c'est l'avenir", tu les écoutes et passe du C au Go. Quelques années plus tard, l'effet de mode disparaît, et on te dit "Rust, c'est l'avenir".

Si c'est comme cela que l'on choisit les langages chez toi, en effet, vous allez avoir un problème. On ne choisit pas un langage, "parce que c'est l'avenir", mais parce qu'il va apporter des avantages (rapidité, fiabilité, ...) et on évite tout particulièrement de le changer sur un projet en cours a moins d'avoir excellentes raison de le faire.

[JPLAROCHE]

je ne veux pas polémiqué mais des solutions dans GCC pour c/c++ comme "-ftree-coalesce-vars -fstack-clash-protection -fstack-protector-all" et d'autre encore peuvent juguler les fuites.

[Uther]

Il y a des solutions palliatives en C et C++ pour limiter la casse, mais c'est très loin de couvrir tout ce que fait Rust en matière de sécurité.

[Pyramidev]

Je pense qu'il l'ont très bien compris, c'est juste qu'il ne visaient pas ce marché. D, Go, ... visaient plus les développeurs d'application de haut niveau, ils n'ont pas remplacé le C car ils n'ont jamais réellement essayé de le faire.

En fait, il existe un sous-ensemble du langage D qui cherche explicitement à remplacer le C. Il est généralement nommé DasBetterC ou BetterC. Avec un compilateur D, cela correspond à l'option -betterC. Cela interdit plusieurs fonctionnalités disponibles en D normal, dont le ramasse-miettes et les exceptions.
Mais ça m'étonnerait que DasBetterC réussisse à s'imposer face à Rust.

[Uther]

c'est vrai que la gestion mémoire est la 1ere source de bug critique en c et c++. mais j'aimerais bien passer a rust, pourquoi pas. mais 99.9% des lib utiles sont en c ou c++

A part au niveau des GUI, L'écosystème de bibliothèque Rust commence quand même à être pas mal fourni, et on peut s'interfacer sans trop de difficulté aux bibliothèques C, et avec un peu plus de travail aux bibliothèque C++.

En fait, il existe un sous-ensemble du langage D qui cherche explicitement à remplacer le C. Il est généralement nommé DasBetterC ou BetterC. Avec un compilateur D, cela correspond à l'option -betterC. Cela interdit plusieurs fonctionnalités disponibles en D normal, dont le ramasse-miettes et les exceptions.
Mais ça m'étonnerait que DasBetterC réussisse à s'imposer face à Rust.

En effet j'en ai entendu parler, cela dit il me semble que c'est quelque chose qui était difficilement utilisable jusqu'à recement, le D n’avait pas vraiment cet objectif à la base.

[Neckara]

-Javascript ne gagne rien du tout en programmation système.

Il s'est quand même bien étendu depuis sa création, de côté client, il a gagné côté serveur, et peut même être utilisé pour des applications desktop.

L'aspect langage unique attire, et il est bien possible qu'il continue à s'étendre.

-Javascript, dans son domaine, est un excellent langage

Heu... tu as déjà fait des manipulations de bits en JS ? .
Au niveau des bêtises du JS, tu peux en trouver des pages et des pages.

C'est pas du tout l'impression que j'ai, par contre chaque fois que je vois une présentions honnête d'un langage qui ne prétend rien de plus que pouvoir fournir une alternative, je vois des défenseurs du C qui se lamentent comme si on allait exiger de remplacer sous 15 jours l'intégralité du code existant pour les mettre définitivement au chômage.

Je vois pas grand monde de sérieux dans l'industrie qui dit, "il faut abandonner C, il faut passer à X", du moins pas de manière absolue, pas sans une étude du contexte qui indique que le changement est vraiment utile et pas sans un plan de transition bien pensé.

Tout du moins, c'est l'impression que j'ai ici en suivant les actualités.

C'est surtout que c'est une très mauvaise approche du problème. Il n' y a pas besoin de chercher un langage vainqueur qui battrait tous les autres. Le problème, c'est "Est-ce que le langage est efficace à remplir sa mission par rapport aux alternatives existantes ?".

Le problème, c'est que tu vas faire un choix à un instant T, mais ce choix, il faudra l'assumer sur une durée qui peut s'étendre à plusieurs années. C'est à dire que l'avenir du langage est très important dans le choix qu'on va faire.

Or, quand l'effet de mode s'arrête, tu aurais peut-être plus de difficultés à recruter des développeurs dans ces langages, les bibliothèques ne seront peut-être pas toutes maintenues régulièrement, etc.
Cela a aussi un coût.

Si c'est comme cela que l'on choisit les langages chez toi, en effet, vous allez avoir un problème. On ne choisit pas un langage, "parce que c'est l'avenir", mais parce qu'il va apporter des avantages (rapidité, fiabilité, ...) et on évite tout particulièrement de le changer sur un projet en cours a moins d'avoir excellentes raison de le faire.

Le fait de dire que "c'est l'avenir", implique l'existence d'avantages par rapport à l'existence, ainsi qu'une obsolescence de l'existant dans le futur.

Ce n'est pas aussi qu'une question de projet, mais d'une dette logiciel qu'il faudra se traîner.
Certes ton projet va durer 1 ans, 2 ans, 5 ans. Mais le code que tu écris pourras être utilisé même 30 ans plus tard.

[23JFK]

La syntaxe de Rust est stabilisée depuis la version 1.0 (2015). Je suis curieux de savoir ce que tu appelle fonctions de substitution.

Je n'ai fait que lire l'article : insert ASM , union/structure.