IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

« 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 , par Patrick Ruiz

39PARTAGES

14  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 21/09/2022 à 0:44
Citation Envoyé par HaryRoseAndMac Voir le message
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.

Citation Envoyé par HaryRoseAndMac Voir le message
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 ...
12  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 20/09/2022 à 23:44
Citation Envoyé par Markand Voir le message
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.

Citation Envoyé par Aiekick Voir le message
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.

Citation Envoyé par OrthodoxWindows Voir le message
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.
10  1 
Avatar de Bousk
Rédacteur/Modérateur https://www.developpez.com
Le 20/09/2022 à 18:57
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.
8  1 
Avatar de leroivi
Membre régulier https://www.developpez.com
Le 21/09/2022 à 12:01
Citation Envoyé par Anselme45 Voir le message

Pour ma part, je constate qu'il y a 2 types de langage informatique: Ceux qui appartiennent à tous le monde (les langage "universel" du style C, Pascal, etc...) et ceux qui sont propriété d'une GAFAM... Quelque soit le langage, qu'il soit promu par un Google, Microsoft ou Apple, ils n'auront une durée de vie qui ne dépendra que de la stratégie marketing de ces entreprises. Et donc...
Attention, 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 ?)
7  0 
Avatar de Astraya
Membre émérite https://www.developpez.com
Le 21/09/2022 à 9:06
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.
7  1 
Avatar de Pierre Louis Chevalier
Expert éminent sénior https://www.developpez.com
Le 21/09/2022 à 13:03
Citation Envoyé par Anselme45 Voir le message
Pensée émue pour les victimes d'un autre forcing de Microsoft, les gogos qui ont cru en Silverlight. Après avoir affirmé au grand dieu, la main sur le coeur, que Silverlight était l'avenir de l'informatique, Microsoft a abandonné le produit en laissant en rase campagne les "gogos" qui avaient cru en ses conseils avisés!!!!!!!!!!!!!!!!!!!
Je 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.
6  0 
Avatar de prisme60
Membre régulier https://www.developpez.com
Le 21/09/2022 à 23:40
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.
6  0 
Avatar de Dymmm
Membre actif https://www.developpez.com
Le 23/09/2022 à 12:34
Si 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.
6  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 21/09/2022 à 13:24
Citation Envoyé par mith06 Voir le message
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, ...)

Citation Envoyé par mith06 Voir le message
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.
4  0 
Avatar de onilink_
Membre émérite https://www.developpez.com
Le 21/09/2022 à 11:34
Citation Envoyé par d_d_v Voir le message
Quand je lis certaines portions de la doc de rust, je me demande si les concepteurs ont réellement travaillé un jour sur des vrais projets. Par exemple, la doc de LinkedList:

Je me demande comment on peut raisonnablement conseiller d'utiliser autre chose qu'une liste chaînée quand on a besoin des performances et du comportement d'une liste chaïnée (performance O(1) lors d'un ajout/retrait d'un élément).
Alors 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 : Sélectionner tout
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
-------------------------------------------------------------------------------
3  0