Discussion :

[Patrick Ruiz]

« 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

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

[Bousk]

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

[Markand]

Encore un qui n'a jamais fait d'embarqué. Je fais spécifiquement du C parce que j'aime savoir ce qu'il se passe à tout moment. D'autant plus que dans l'embarqué, rien que déclarer une variable trop large sur la pile est déjà risqué.

[OrthodoxWindows]

Mark Russinovich me déçois beaucoup. C'était l'un des dernières personnes compétente de chez Microsoft qui comprenait vraiment le fonctionnement de Windows. Dommage .

[Aiekick]

rust remplace a merveille le c, mais il ne peut pas remplacer le c++ ou partiellement. il ne respecte pas le paradigm object.
il doit donc etre utilisé la ou perf et securité sont critique, pas pour tout est n'importe quoi

[OrthodoxWindows]

rust remplace a merveille le c, mais il ne peut pas remplacer le c++ ou partiellement. il ne respecte pas le paradigm object.
il doit donc etre utilisé la ou perf et securité sont critique, pas pour tout est n'importe quoi

Rust remplace le C pour ceux qui préfèrent le Rust au C, ce qui n'est pas du tout la même chose .

[Uther]

Encore un qui n'a jamais fait d'embarqué. Je fais spécifiquement du C parce que j'aime savoir ce qu'il se passe à tout moment. D'autant plus que dans l'embarqué, rien que déclarer une variable trop large sur la pile est déjà risqué.

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

rust remplace a merveille le c, mais il ne peut pas remplacer le c++ ou partiellement. il ne respecte pas le paradigm object.
il doit donc etre utilisé la ou perf et securité sont critique, pas pour tout est n'importe quoi

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.

Rust remplace le C pour ceux qui préfèrent le Rust au C, ce qui n'est pas du tout la même chose .

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.

[OrthodoxWindows]

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.

Pourtant c'est même le titre d'un article en ce moment en une sur Developpez.com :

Après 31 ans, un deuxième langage sera admis pour le développement du noyau Linux : c'est le Rust,
Considéré par plusieurs comme candidat idéal pour la mise au rebut du langage C

Clairement, cet article informe que certaines personnes milites pour un abandon du C, ce que je trouve absurde et inacceptable. D'ailleurs, plusieurs projets Rust sur Github témoignes en ce sens.

[Astraya]

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.

[Uther]

Est-ce qu'il y a des chose que l'on peut faire en C/C++ et qui ne sont faisable en Rust?

Tout 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, ...)

Est-ce que l'on peut faire de la programmation embarqué en Rust? C.a.d faire un (petit) soft qui tient dans 32kio pour un microcontrôleur 8/16 bit.
Les fabriquant de microcontrôleur commencent-ils à intégrer le Rust dans leur SDK?

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.

[Aiekick]

Rust remplace le C pour ceux qui préfèrent le Rust au C, ce qui n'est pas du tout la même chose .

ca me semblat evident mais a priori il faut reexpliquer... par "remplacer a merveille le c" c'est "il peut faire tout ce que peu faire le c" a part peu etre l'integration de code asm, quoi que.

evidemment que les gens font ce qu'ils veulent, mais je ne parlais pas de ca..........

[HaryRoseAndMac]

En attendant, le C reste le langage le plus performant et je ne sais pas d'où ils sortent que le C est moins secure, mais ... ce n'est pas vrai.
Le seul langage plus performant que le C, c'est l'assembleur ...

Source : https://benchmarksgame-team.pages.de...test/rust.html

[Uther]

En attendant, le C reste le langage le plus performant [...]
Le seul langage plus performant que le C, c'est l'assembleur ...

Source : https://benchmarksgame-team.pages.de...test/rust.html

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

et je ne sais pas d'où ils sortent que le C est moins secure, mais ... ce n'est pas vrai.

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

[HaryRoseAndMac]

Je pense que tu n'as pas bien regardé ta source, parce que le Rust devance le C sur la moitié de 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 niveau 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 ...

Effectivement, à voir.

[mith06]

Est-ce qu'il y a des chose que l'on peut faire en C/C++ et qui ne sont faisable en Rust?

Est-ce que l'on peut faire de la programmation embarqué en Rust? C.a.d faire un (petit) soft qui tient dans 32kio pour un microcontrôleur 8/16 bit.

Les fabriquant de microcontrôleur commencent-ils à intégrer le Rust dans leur SDK?

[locus]

Je ne suis pas opposé au Rust mais je trouve que ce langage et son environnement n'ont pas atteint un certain niveau de maturité pour être réellement exploitables.
Depuis le coup de python 2 à python 3 et ses changements, je me méfie de certains langages très récents car on peut tout bouleverser en quelques années voir quelques mois (syntaxe, style de programmation...).

Alors initier les prochains projets en les concevant sous Rust, OK mais j'ai besoin de preuve de sa stabilité sur le très très long terme afin de ne pas passer mon temps à refaire mon code.
Déjà que certaines frameworks passent leur temps à évoluer au point que les dévs n'arrivent plus à suivre ou doivent retoucher du code legacy de manière hasardeuse.

[prisme60]

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

[smarties]

Pour moi RUST est suffisamment mature pour un certains nombre de projets.
C'est évident qu'il manque des bibliothèques et qu'il faut préparer les projets en amont de ce côté là.

C et C++ seront encore présent longtemps mais leur chaîne de compilation est souvent problématique sur les gros projets quand il faut installer beaucoup de bibliothèques. De ce que j'ai peu croiser, ce n'était pas forcément bien documenté sur ce point.

Au niveau sécurité, il n'y a pas photo. Quand j'ai fait du C et du C++ il y a longtemps j'avais souvent des "Segmentation fault" que je n'ai pas en RUST. Etre averti en amont par le compilateur est vraiment bien.

Pour des projets stables et qui n'ont pas eu de bugs remontés depuis longtemps, ça ne servirait pas à grand chose de les réécrire.

Pour les nouveaux projets, je suis d'avis de se poser la question entre rester sur C ou C++ ou de le développer en RUST... surtout si le process manque d'industrialisation.

[locus]

Tant que l'on devra faire appel aux FFI par manque de bibliothèques propres à rust, je me dis que Rust est encore loin d'être un environnement mature. Même avec Python, je dois utiliser ctypes chose qui m'agace.

[imperio]

Tant que l'on devra faire appel aux FFI par manque de bibliothèques propres à rust, je me dis que Rust est encore loin d'être un environnement mature. Même avec Python, je dois utiliser ctypes chose qui m'agace.

Tant que des OS sont écrits en C tu veux dire ? Je crains fort que l'on doive attendre longtemps alors...