« C'est le moment d'arrêter d'initier de nouveaux projets en C ou C++ et de passer à Rust », selon Mark Russinovich de Microsoft
Qui recommande Rust pour une meilleure sécurisation des logiciels
Le 2022-09-20 17:46:55, par Patrick Ruiz, Chroniqueur Actualités
Go, C3, D, … La liste des langages présentés comme des alternatives au C ou au C++ s’allonge avec les années qui passent. Celui qui a frappé un grand coup dans ces tentatives multiples de mise au rebut du langage C est le Rust. En effet, le noyau Linux s’ouvre de plus en plus au langage de programmation système de Mozilla. Ainsi, des voix s’élèvent de plus en plus pour en faire le successeur attitré des langages C et C++. Sans détour Mark Russinovich de Microsoft vient de déclarer que « c’est le moment d’arrêter d’initier de nouveaux projets en langages C ou C++ et de passer à Rust. »
Chez Amazon par exemple, on est d’avis que « choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C, mais une efficacité énergétique et une performance d’exécution que seul le C offre. » En effet, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que Mark Russinovich recommande le Rust plutôt que le C ou le C++.
Après 31 ans, un deuxième langage sera admis pour le développement du noyau Linux : c’est le Rust. La prise en charge de Rust pour le développement du noyau Linux est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel 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. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C.
Le créateur du langage C3 dresse néanmoins une longue liste de raisons pour lesquelles les initiatives de mise au rebut du langage C sont vouées à l’échec. Il s’exprime sur divers aspects dont :
La chaîne d'outils du langage C
Le langage C n'est pas seulement le langage lui-même, mais aussi tous les outils de développement développés pour ce langage. Vous voulez faire une analyse statique de votre code source ? - Il y a beaucoup de gens qui travaillent sur ce sujet pour le C. Des outils pour détecter les fuites de mémoire, les courses de données et autres bogues ? Il y en a beaucoup, même si votre langage est mieux outillé.
Si vous voulez cibler une plateforme obscure, il est probable que vous utilisiez le C. Le statut du C en tant que lingua franca de l'informatique d'aujourd'hui fait qu'il vaut la peine d'écrire des outils pour ce langage, et de nombreux outils sont donc écrits.
Si quelqu'un a mis en place une chaîne d'outils qui fonctionne, pourquoi risquer de changer de langage ? Un "meilleur C" doit apporter beaucoup de productivité supplémentaire pour motiver le temps passé à mettre en place une nouvelle chaîne d'outils. Reste même à savoir si cela est possible.
Les incertitudes d'un nouveau langage
Avant qu'un langage ne soit arrivé à maturité, il est probable qu'il comporte des bogues et qu'il soit modifié de manière significative pour résoudre les problèmes de sémantique du langage. Et le langage est-il même conforme à la publicité ? Il offre peut-être quelque chose comme "des temps de compilation exceptionnels" ou "plus rapide que le C" - mais ces objectifs s'avèrent difficiles à atteindre lorsque le langage ajoute l'ensemble des fonctionnalités.
Et qu'en est-il des mainteneurs ? Bien sûr, un langage open source peut être bifurqué, mais je doute que de nombreuses entreprises soient intéressées par l'utilisation d'un langage qu'elles pourraient être obligées de maintenir plus tard. Parier sur un nouveau langage est un gros risque.
Le fait que le langage pourrait tout simplement ne pas être assez bon
Le langage s'attaque-t-il aux véritables points faibles du C ? Il s'avère que les gens ne sont pas toujours d'accord sur ce que sont les points sensibles du C. L'allocation de mémoire, la gestion des tableaux et des chaînes de caractères sont souvent délicates, mais avec les bonnes bibliothèques et une bonne stratégie mémoire, elles peuvent être minimisées. Le langage ne traite-t-il pas des problèmes dont les utilisateurs avancés ne se soucient pas vraiment ? Si c'est le cas, sa valeur réelle pourrait être beaucoup plus faible que prévu.
Et pire encore, que se passe-t-il si le langage omet des fonctionnalités cruciales qui sont présentes en C ? Des fonctionnalités sur lesquelles les programmeurs avancés du C comptent ? Ce risque est accru si le concepteur du langage n'a pas beaucoup utilisé le C, mais vient du C++, du Java, etc.
L’absence de développeurs expérimentés pour un nouveau langage
Un nouveau langage disposera naturellement d'un groupe beaucoup plus restreint de développeurs expérimentés. Pour toute entreprise de taille moyenne ou grande, c'est un énorme problème. Plus il y a de développeurs disponibles pour une entreprise, mieux elle se porte.
De plus, si l'entreprise a l'expérience du recrutement de développeurs C, elle ne sait pas comment recruter pour ce nouveau langage.
L'ABI C
Si le langage ne peut pas facilement appeler - ou être appelé - par du code C, alors toute personne utilisant le langage devra faire un travail supplémentaire pour faire à peu près tout ce qui est interface avec du code extérieur. C'est potentiellement un énorme inconvénient.
Source : Mark Russinovich
Et vous ?
Êtes-vous en accord avec les griefs portés à l'endroit de C/C++ en matière de sécurité ? Le problème n'est-il pas plutôt celui de la qualité des développeurs ?
Le C et le C++ a-t-il vraiment besoin de remplaçants surtout en matière de programmation système ?
Votre entreprise a-t-elle adopté le langage Rust ? Si oui, pour quelles raisons ?
Quel commentaire faites-vous de l’argumentaire du créateur du langage C3 ? Quels sont les aspects les plus pertinents ? Quels sont ceux qui le sont moins ?
Êtes-vous aussi d’avis que la communauté Linux anticipe non seulement sur les départs en retraite des actuels mainteneurs et sur les qualités que Rust offre en comparaison au langage C ?
Pourquoi les langages C et C++ pourraient-ils encore avoir de longues années devant eux ?
Voir aussi :
L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé
Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D
C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust
Chez Amazon par exemple, on est d’avis que « choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C, mais une efficacité énergétique et une performance d’exécution que seul le C offre. » En effet, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que Mark Russinovich recommande le Rust plutôt que le C ou le C++.
Après 31 ans, un deuxième langage sera admis pour le développement du noyau Linux : c’est le Rust. La prise en charge de Rust pour le développement du noyau Linux est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel 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. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C.
Le créateur du langage C3 dresse néanmoins une longue liste de raisons pour lesquelles les initiatives de mise au rebut du langage C sont vouées à l’échec. Il s’exprime sur divers aspects dont :
La chaîne d'outils du langage C
Le langage C n'est pas seulement le langage lui-même, mais aussi tous les outils de développement développés pour ce langage. Vous voulez faire une analyse statique de votre code source ? - Il y a beaucoup de gens qui travaillent sur ce sujet pour le C. Des outils pour détecter les fuites de mémoire, les courses de données et autres bogues ? Il y en a beaucoup, même si votre langage est mieux outillé.
Si vous voulez cibler une plateforme obscure, il est probable que vous utilisiez le C. Le statut du C en tant que lingua franca de l'informatique d'aujourd'hui fait qu'il vaut la peine d'écrire des outils pour ce langage, et de nombreux outils sont donc écrits.
Si quelqu'un a mis en place une chaîne d'outils qui fonctionne, pourquoi risquer de changer de langage ? Un "meilleur C" doit apporter beaucoup de productivité supplémentaire pour motiver le temps passé à mettre en place une nouvelle chaîne d'outils. Reste même à savoir si cela est possible.
Les incertitudes d'un nouveau langage
Avant qu'un langage ne soit arrivé à maturité, il est probable qu'il comporte des bogues et qu'il soit modifié de manière significative pour résoudre les problèmes de sémantique du langage. Et le langage est-il même conforme à la publicité ? Il offre peut-être quelque chose comme "des temps de compilation exceptionnels" ou "plus rapide que le C" - mais ces objectifs s'avèrent difficiles à atteindre lorsque le langage ajoute l'ensemble des fonctionnalités.
Et qu'en est-il des mainteneurs ? Bien sûr, un langage open source peut être bifurqué, mais je doute que de nombreuses entreprises soient intéressées par l'utilisation d'un langage qu'elles pourraient être obligées de maintenir plus tard. Parier sur un nouveau langage est un gros risque.
Le fait que le langage pourrait tout simplement ne pas être assez bon
Le langage s'attaque-t-il aux véritables points faibles du C ? Il s'avère que les gens ne sont pas toujours d'accord sur ce que sont les points sensibles du C. L'allocation de mémoire, la gestion des tableaux et des chaînes de caractères sont souvent délicates, mais avec les bonnes bibliothèques et une bonne stratégie mémoire, elles peuvent être minimisées. Le langage ne traite-t-il pas des problèmes dont les utilisateurs avancés ne se soucient pas vraiment ? Si c'est le cas, sa valeur réelle pourrait être beaucoup plus faible que prévu.
Et pire encore, que se passe-t-il si le langage omet des fonctionnalités cruciales qui sont présentes en C ? Des fonctionnalités sur lesquelles les programmeurs avancés du C comptent ? Ce risque est accru si le concepteur du langage n'a pas beaucoup utilisé le C, mais vient du C++, du Java, etc.
L’absence de développeurs expérimentés pour un nouveau langage
Un nouveau langage disposera naturellement d'un groupe beaucoup plus restreint de développeurs expérimentés. Pour toute entreprise de taille moyenne ou grande, c'est un énorme problème. Plus il y a de développeurs disponibles pour une entreprise, mieux elle se porte.
De plus, si l'entreprise a l'expérience du recrutement de développeurs C, elle ne sait pas comment recruter pour ce nouveau langage.
L'ABI C
Si le langage ne peut pas facilement appeler - ou être appelé - par du code C, alors toute personne utilisant le langage devra faire un travail supplémentaire pour faire à peu près tout ce qui est interface avec du code extérieur. C'est potentiellement un énorme inconvénient.
Source : Mark Russinovich
Et vous ?
Voir aussi :
-
UtherExpert éminent séniorJe pense que tu n'as pas bien regardé ta source, parce que le Rust devance le C sur la moitié des programmes testés.
De manière générale, on constate que deux programmes qui ont le même soin apporté à l'optimisation ont généralement des performances similaires en Rust et en C.
Renseigne toi un minimum sur le Rust et tu verras que le niveau de préoccupation à propos de la sécurité entre le Rust et le C est sans appel. Les comportement indéfinis du C que l'on peut facilement déclencher par inadvertance ne peuvent l'être en Rust a moins de le spécifier spécifiquement.
De part sa conception, le Rust empêche par défaut de compiler les programmes qui peuvent contenir des erreurs de sécurité mémoire comme les doubles libération, utilisation après libération, variable non initialisées, data race ...le 21/09/2022 à 0:44 -
UtherExpert éminent séniorEncore un qui n'a jamais fait de Rust
.
Rust permet de contrôler aussi bien que le C ce qui va sur la pile et ce qui n'y va pas.
Certes, on ne peut pas forcément convertir directement en Rust un programme C++ en gardant la même architecture de classes, mais ça ne veut pas dire que l'on ne peut pas faire les choses de manière tout aussi efficace. Il faut juste apprendre à architecturer différemment ses programmes.
Quand on dit que Rust remplace le C, ça veut dire qu'il peut techniquement être utilisé a peu près partout ou on utilise actuellement le C, pas que tout le monde est obligé de le faire.le 20/09/2022 à 23:44 -
BouskRédacteur/ModérateurHônnetement, Rust est sans doute un excellent langage bourré de qualités, mais de voir un tel forcing qui répète juste ad nauseam "Utilisez Rust, c'est le plus mieux" non stop, ça ne me donne pas du tout envie de m'y attarder.
Ça, et le fait que je n'ai pas de temps libre à y accorder, que ma carrière en C++ est tout à fait satisfaisante et que la suite de celle-ci, toujours en C++, est également de bon augure.le 20/09/2022 à 18:57 -
leroiviMembre régulierAttention, Rust ne vient pas de chez microsoft, c'est un ingénieur microsoft qui se prononce dessus mais c'est tout. C'est Mozilla qui a initié le projet, pas une GAFAM, puis il a monté un groupe indépendant pour gérer le langage. Il a son propre commité, comme C++ en somme. Alors certes les GAFAM ont leur poids, mais ils ne sont pas à la gouvernance. D'autant qu'avec l'intégration de programme écrit en Rust dans le kernel Linux, une partie de la communauté libre va s'investir dans cette gouvernance aussi. (la linux foundation n'aurait pas déjà sa place à la table ?)le 21/09/2022 à 12:01
-
AstrayaMembre chevronnéIl n'a jamais été question de remplacer le C ou le C++. Ce sont 2 langages irremplaçables, dû moins pas avant plusieurs décennies au vu de l'écosystème de ces langages et le long chemin que Rust doit parcourir pour arriver au même résultat.
Il est question de faire des NOUVEAUX projets en Rust.
Maintenant, je ne suis pas entièrement d'accord avec cette approche simpliste. Un nombre incalculable d'API sont écrites et fournit en C++ pour les applications desktop et la FFI entre C++ et Rust est parfois tout simplement impossible directement.
Je constate que il y a un gros engouement pour Rust mais surtout par des gens venant de Python, Javascript etc, mais pas une majorité de gens qui font du dev système, venant de ces gens là ( j'en fais partie) l'adoption est bien plus frileuse a juste titre.
Les cibles supportées tier 1 de Rust sont bien moindre que C, un constructeur fournira un support avec un compilateur C aujourd'hui, pas Rust.
J'aime beaucoup rust mais aujourd'hui je ne le recommanderai pas pour des très gros projets. De plus, certains métiers veulent de la productivité au prix des crashs et fuites mémoires comme le jeu vidéo et les patch day one.le 21/09/2022 à 9:06 -
Pierre Louis ChevalierExpert éminent séniorJe ne pense pas que cela vienne de la hiérarchie de Microsoft, c'est juste un people connu de la tech, il occuperait un poste très important dans la division Azure si j'ai bien compris, qui exprime son avis publiquement, et il se trouve qu'il est chez Microsoft.
Après je pense que les questions posées sont intéressantes, mais il n'y a pas de réponse simple, sinon ça ferait pas débat.le 21/09/2022 à 13:03 -
prisme60Membre régulierJ'ai proposé à ma boite de porter et faire les évolutions de notre projet sous Rust, mais le responsable était frileux. Beaucoup de notre code se remplaçait par des bibliothèques (Crates), ce qui nous évitait de le réécrire, et nous assurait de respecter les bonnes pratiques du Rust. Une bibliothèque statique pour la gestion du dongle de protection était appelable via FFI (cela demander évidemment d'utiliser le mot clé "unsafe" que l'on essaye d'éviter).
Je leur affirmais que vu le peu de source de redévelopper le soft (20 fichiers c++), mais qui utilise massivement du multithreading (que j'avais moi-même écrit auparavant, donc je ne m'attaque pas à quelque chose que je ne comprends pas).
Comme l'outil doit en plus respecter le niveau outil T2 (en-50128 norme de sureté de fonctionnement logiciel ferroviaire : outils), Rust convenait parfaitement et en plus garantit une stabilité de fonctionnement et gestion des erreurs.
Mais on m'a répondu, que j'étais le seul à connaître le Rust, et effectivement en continuant sur ce genre de stratégie, je vais continuer à écrire du code Rust pour mes projets persos. le 21/09/2022 à 23:40 -
DymmmMembre actifSi j'avais a choisir entre C et Rust pour le boulot alors je choisirais Rust. J'ai trop souvent eu des collègues prétendant savoir développer en C (ou C++) et produisant du code de merde. Si Rust peut limiter la casse alors je suis partant.le 23/09/2022 à 12:34
-
UtherExpert éminent séniorTout dépends ce qu'on entent par là. En ce qui concerne les bonne performances, la prédictibilité et l'accès aux ressources bas niveau, le Rust fait aussi bien que le C/C++ ce qui le rend tout a fait utilisable pour des applications très bas niveau.
Pour ce qui est des fonctionnalité du langage tout ce qui est faisable en C l'est en Rust (sauf le goto) même si les choses potentiellement problématique sont volontairement plus complexes a mettre en place pour éviter qu'elles soient utilisées par inadvertance.
Comparé au C++ c'est plus mitigé. Certaines fonctionnalités ne sont pas encore aussi avancées (généralisation, constexpr, ...) mais progressent, d'autres sont volontairement écartée pour garder un langage simple (template metaprogramming, surcharge classes héritées, ...) mais sont remplacés par d'autre mécanismes (traits, génériques, macro hygiéniques, ...)
Le langage Rust permet de faire des programes qui s'optimisent à peu près aussi bien en taille que le C, mais sa plus grosse limitation a l'heure actuelle est qu'il n'est en effet pas encore supporté par la plupart des tout petits microcontrôleurs.le 21/09/2022 à 13:24 -
onilink_Membre émériteAlors perso, dans le domaine du jeu vidéo, j'ai très rarement besoin de listes chaînées.
Et effectivement niveaux perfs/cache c'est pas incroyable, surtout si chaque élément de la liste est alloué dynamiquement.
Il ne faut pas oublier qu'on peut aussi utiliser un tableau comme base d'une liste chaînée, ce qui permettra de mieux exploiter le cache...
Petite expérience sur mon projet:
- 1689 occurrences de std::vector
- 505 std::array
- 183 std:map
- 89 std:set
- 28 std::list
- 24 std::queue
- 9 std::stack
Et pour donner un contexte, cloc sur le projet:
Code : 1
2
3
4
5
6
7
8------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- C++ 1021 34453 24177 186475 C/C++ Header 1229 32843 27452 70651 ------------------------------------------------------------------------------- SUM: 2250 67296 51629 257126 -------------------------------------------------------------------------------
le 21/09/2022 à 11:34