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...

[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!!!

[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.

[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!

[air-dex]

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

M'est avis que Mozilla s'est surtout posé les bonnes questions et a mûrement réfléchi à son "C-killer", ce qui donne quelque chose de bien conçu. Ils font ça comme il faut de A à Z et j'espère pour eux que ça va payer !

De Go je me souviens que le langage était surtout présenté comme quelque chose "qui compile plus vite que C++". Mais au final ce n'est pas ça qui compte, le temps gagné par les développeurs pendant le développement n'étant rien face au temps gagné par les utilisateurs une fois en production.

C existera encore et fera encore vivre des développeurs dans 100 ans. Mais est-ce que ça sera toujours un langage très utilisé ou bien un langage de niche parce que Rust aura pris sa place ? Mystère.

[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

[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.

[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 ?

[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.

[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.

[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.

[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.

[Invité]

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.

La programmation web et la programmation d'appli desktop, ce n'est pas de la programmation système.
Si tu regardes les 20 premières secondes de la vidéo de l'article, il y a des exemples de prog système : bios, firmware, bootloaders, OS, etc
Perso je connais pas beaucoup de bios codé en JS...

[Uther]

Heu... tu as déjà fait des manipulations de bits en JS ? .

Justement "dans son domaine" (sous-entendu le web je suppose) on ne fait pas énormément de manipulation de bit.

Au niveau des bêtises du JS, tu peux en trouver des pages et des pages.

Je suis entièrement d'accord que le Javascript est un langage bancal, mais pour un défenseur du C avec ses presque 200 "undefined behavior", c'est un peu l’hôpital qui se moque de la charité.

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

Il y a une grosse différence entre les annonce sur les sites d'actualité qui cherche forcément un peu le sensationnel et ce qui se passe dans les équipes de dev. On ne choisit pas un langage uniquement parce qu'on a vu un joli article mais parce que l'on a pesé les impact positif comme négatif que son utilisation.

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.

Clairement, la complexité de maintenance et la durée de vie des technologies, fait partie des élément à prendre en compte dans le choix d'un langage, mais leur importance peut varier en fonction des projets.

Je ne me jetterais pas, pour le moment sur le Zig ou le C2 dont l'avenir parait très incertain, sauf pour des projets type R&D dont je sais qu'ils auront une courte durée de vie et très peu d'intervenants.
Par contre quand on voit l’investissement actuel dans le Rust ou le Go, je pense que ces langages peuvent raisonnablement être considérés viables.

En tant qu'utilisateur je serais plus convaincu par une évolution du C qui permette une gestion de la mémoire plus simple et plus sur.
Mais j'imagine que ca ne doit pas être facile, ca restera sans doute un doux rêve dans ma tête.

Beaucoup ont essayé, mais au final se sont rendu compte que c'est impossible de corriger les principaux défauts du C sans en faire un langage fondamentalement incompatible donc de fait un nouveau langage.
Même le C++ core guideline qui devaient établir un sous-ensemble et des pratique d'usage sures du C++ ont revus leur ambition à la baisse et ne prétendent plus garantir la sécurité mémoire.

[el_slapper]

(.../...)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.(.../...)

Je ne connais rien aux technos dont vous parlez ici(à part JS, dont je n'ai qu'une connaissance que très superficielle), mais ça, ça me parle beaucoup. La "meilleure solution" du point de vue purement technique peut être un piège mortel.

[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.

[Uther]

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

Ok, tu parles des fonctionnalités expérimentales qui ne sont pas encore disponible dans la version stable du compilateur. C'est vrai qu'il y en a un certain nombre.
Mais le langage en lui même est stable : le code compilé avec une version stable du compilateur et garanti de continuer à compiler avec les version à venir du compilateur.

Ça n'a rien de différent du C : lui aussi a ajouté des nouveautés au langage au fur a mesure de son évolution. D'ailleurs sur le problème de l'assembleur inline, le C est même pire que Rust : cette fonctionnalité ne fait pas partie du standard C et chaque compilateur C a sa propre syntaxe.