Pardon, en effet j'ai confondu avec un message de commandantFred.Envoyé par OuftiBoy
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Pardon, en effet j'ai confondu avec un message de commandantFred.
Soit !
Cela dit, vous constaterez plus bas que GCC donne le même résultat. Pour moi (35 ans de dev), cette histoire est un hoax.
Pour revenir au topic, La Maison Blanche etc...
Les gouvernements réalisent, un peu tard, que leurs pays sont mis en danger par du software éparpillé sur tout leur territoire. Comme je l'ai fait pendant des décennies, ce software pilote des ascenseurs de centaines de mètres de haut, des systèmes vitaux d'avions, ... L'exemple donné dans un message précédent sur les SGBD citait SqLite... Vous connaissez l'histoire de SqLite ? Il a été développé pour piloter les missiles de croisière nucléaires américains, rien que ça...
Pourtant, le problème est sans objet dans ce cas. Ces engins ne sont pas connectés à l'internet. Ils sont évidemment programmables à distance mais IP n'est plus utilisé par les militaires depuis longtemps. Toute la stack de communication tactique est non seulement confidentiel défense mais sécurisée par des chiffrages, eux-mêmes inaccessibles au public.
Les systèmes critiques (j'ai pas mal d'expérience là dessus) sont quand même bien sécurisés.
Ce qui ne l'est pas, c'est le logiciel lambda que le commercial Iota a installé sur son laptop pour faire du CRM à distance, avec la complicité de l'opératrice Dzeta qui récupère les données sur le réseau de l'entreprise Omicron avec la bénédiction de tout le personnel dirigeant, trop content de suivre le travail des centaines de personnes en temps réel sur un compte partagé par tous les itinérants.
C'est le software génial qui aide toutes les boites du BTP à passer commande de fournitures et obtenir des ristournes chez les grossistes.
Et encore, les applis en B2B sont au moins protégées par un pare-feu. Il y a bien pire. Les petits open source sympas installés par des millions de quidams dont N% n'ont même pas activé le pare feu de leur OS...
En ce moment, plusieurs chaines de TV diffusent un message de la DGSI qui alerte sur les failles d'Outlook. Je n'avais jamais vu ça avant.
Il y a aussi cette directive, toujours de la DGSI qui oblige les développeurs français à rester joignables au cas où leur software serait identifié comme vulnérable par les services de l'état... (je peux retrouver cette directive et la copier ici...)
Quand je travaillais sous devoir de réserve, j'ai explicitement demandé à ce qu'on rende obligatoire la maintenance du code dans les appels d'offre. Presque aucun éditeur ne la propose pour limiter les coûts et la sécurité est souvent traitée comme un pétard mouillé dans les bureaux. Il y a plein de gens, sans offense, un peu comme vous, qui sont tellement habitués à retourner la responsabilité sur les autres que la sécurité est le problème exclusif du premier qui en parle. La seule évocation de ce problème rend le malheureux qui l'évoque "suspect".
Et comme vous le dites, remplacer CC++ par Rust est un chantier pharaonique.
On n'a même pas parlé des autres langages/archis.
D'où ma conclusion : La Maison Blanche a non seulement raison d'alerter sur la sécurité du software, mais il se passe exactement la même chose en France (et en Europe).
Par contre, je trouve qu'elle n'est pas dans son rôle en parlant de Rust. Même si tout le monde est plus ou moins d'accord pour migrer les OS vers Rust à court terme, Ce n'est pas au gouvernement de décider ça.
Le C++ n'a jamais été un langage sécurisé et il ne le sera jamais. Il n'a pas été conçu pour. Son concepteur l'a justement conçu pour que le développeur soit "libre". Son amour du "bas niveau", la plupart du temps inutile, l'en empêche. Son compilateur laisse tout passer, presque. Il y a toujours eu des alternatives comme Ada, suffisamment orienté-objet pour réaliser tous les systèmes jusqu'aux plus grands. Et pour qui le compilateur est une aide précieuse, sauf si on le débranche explicitement à ses risques et périls (Ariane 5).
Quand à la lisibilité, la plupart du temps, je n'ai pas vu du code C++ écrit pour être lisible par des développeurs et aucun code programmé avec un langage à la syntaxe du C/C++ n'est lisible par l'équipe client non-développeur.
Essayez toujours d'imposer une règle comme "Si le client en revue de code ne l'accepte pas, réécrivez"... En Ada, ou en d'autres langages qui sont de l'Anglais standardisé, il est possible, et c'est de bonne pratique, que de d'écrire des sources qui sont du pseudo-code, c'est-à-dire du niveau de la conception. On gagne sur les deux tableaux: moins de défauts et moins de travail, donc plus de productivité.
Également, je n'ai jamais vu un seul projet C++ donner une garantie d'achèvement après travaux de trois ans de correction gratuite de défauts. Après trois ans en production, je n'ai jamais vu un projet C++ avoir la productivité finale d'un projet Ada. En effet, si on ne mesure que l'écriture du code, il se peut qu'un développeur C++ aille plus vite. Mais dès lors qu'il faut obtenir de la fiabilité, ce qui exactement l'objet de la publication mentionnée, la productivité s'effondre en corrigeant défaut après défaut, sans jamais obtenir le niveau de fiabilité nécessaire...
C'est le malheur de notre industrie que de préférer le "vite fait mal fait" au "ce qui se conçoit bien s'énonce aisément...", c'est à dire que moins on a de temps, et plus il faut réfléchir et concevoir avant d'y aller. Une seule fois.
Rust a des fondations plus solides que C++, mais ne confondons pas les problèmes intrinsèques au langage et les problèmes culturels qui l'entourent.
À propos de problèmes culturels, dans un sondage de Jetbrains de 2021, parmi les développeurs qui n'écrivaient aucun test automatisé, il y avait :
- 46 % des développeurs C et
- 30 % des développeurs C++ alors qu'il n'y avait que
- 3 % des développeurs Scala.
Là, il s'agit beaucoup plus d'un problème de niveau des développeurs que du langage.
À part ça, hier, j'ai lu un témoignage de Philippe Gaultier sur des projets C++ sur lesquels il a travaillé et il y a plusieurs passages qui m'ont fait rire.
Concernant les fuites de mémoire, c'est à la fois un problème culturel et un problème du langage C++. Beaucoup de développeurs ont appris new et delete avant std::make_unique. En langage C, il n'y a pas de destructeur appelé automatiquement, donc c'est un problème du langage.
Concernant les use after free, c'est un problème des langages C et C++, car ils n'ont pas le borrow checker de Rust.
Mais, en entreprise, si tu dis que la plupart du code C++ que tu as lu n'était même pas lisible par des développeurs C++, ce n'est pas la faute du C++, en tout cas pas si on le compare aux autres langages mainstreams. Par exemple, si le problème n'est pas bien décomposé en sous-problèmes ou si les fonctions et les variables sont mal nommées, ce n'est pas en passant à un autre langage de programmation que cela corrigera le problème.
Du pseudo-code relu par des gens qui ne sont pas développeurs ?! Cela m'étonne, à moins qu'il s'agisse de personnes qui ont un peu appris la programmation pendant leurs études post-bac puis qui se sont orientées vers autre chose. Quel est le profil des relecteurs que tu évoques ?
Surtout que ce n'est rapide qu'au tout début. Après accumulation de la dette technique, on bascule dans la phase "lentement fait mal fait" avec plein d'incidents en prod.
Ou tout simplement d'IDE ou de bibliothèque standard
Quelles sont les tests intégrés directement à Visual ou Qt Creator?
Et les développeurs embarqués c'est quel IDE ?
Merci pour l'article.
En effet, les relecteurs font partie de la maîtrise d'ouvrage, ce sont des personnes avec des métiers techniques ou commerciaux ayant une culture scientifique ou littéraire mais pas nécessairement de programmation.
Oui, je confirme, le jalon est dur à passer, et nécessite de très bonnes règles de conception et de programmation, si l'on veut que ce genre de profil accepte même de relire.
Par ailleurs, j'adhère totalement à la nécessité des tests, dans le cadre global du plan de validation du logiciel (et du système).
Memory leaks vs. destructeur
J'ai eu ce problème en C# en utilisant une librairie commerciale écrite en C++ et qui fuitait méchamment.
Après avoir tout essayé, même la tête en bas en récitant des formules magiques. La RAM baissait inexorablement (vu depuis le gestionnaire de tâches), jusqu'à l'écran bleu. Crash mortel qui obligeait à redémarrer un serveur alors que l'appli tournait en temps réel sur une plateforme logistique surbookée. C'était le chaos.
En désespoir de cause, j'ai écrit un petit exécutable indépendant nommé "défragmenteur" que je lançais depuis l'appli, juste avant de la fermer (l'appli).
Défragmenteur attendait 3 secondes et relançait l'appli. Il ne faisait que ça, attendre puis relancer son appelant avec une ligne de commande qui restaurait les variables principales sauvegardées par l'appli avant de quitter.
Le miracle, c'est que je récupérais toute la mémoire perdue dans les memory leaks. Cette intervention m'a valu des félicitations et un succès commercial pour mon employeur.
En effet, chaque New ou malloc demande de la ram au système qui stocke au passage l'id du process. Quand l'application se ferme, tous les malloc et les New du thread actif sont libérés, y compris dans les dll synchrones (qui tournent dans le même thread).
Donc, pour les cas désespérés, il faut fermer le process qui fuite et le relancer.
Ok, effectivement, une fuite mémoire n'est pas une vulnérabilité. C'est un bug sur lequel on n'a pas toujours le contrôle.
Une vulnérabilité comme celles dont parle la Maison Blanche ou la DGSI en France, c'est un "exploit" de hacker qui lui permet de faire des dégâts dans le système ou dans le réseau privé d'une boite.
A grande échelle, ça peut même mettre un pays en faillite. Ca peut espionner, voler, tuer, stopper des machines de survie dans un hôpital, faire exploser des centrales électriques, faire tomber des avions, détruire des stocks d'uranium, provoquer des incendies, des guerres, la destruction de l'humanité, ....
Donc, les politiques qui demandent que le software soit mieux protégé sont bien dans leur rôle.
Si les développeurs maîtrisent le code écrit normalement pas de problème mémoire ou autres. Mais certaines applications complexes reprisent par plusieurs équipes de développement peuvent exposer des failles mémoire ou de buffer overflow ou autres encore. Mais je pense que c'est pas si répandu comme problème. C'est un peu exagéré de voire des défaillances à chaque occasion. Par curiosité sur les milliers d'applications écrites surtout en C et en C++ dans les bibliothèques de Linux à combien estimer le pourcentage d'applications présentant ce type particulier de bogues sur la mémoire ? 1% 5% 10% 20% 40% ...99% . A ma connaissance ce sont surtout les environnements graphiques qui sont souvent conçus avec un certain mépris pour la libération des parties allouées. Maintenant aussi c'est difficile de considérer en vrac toutes les applications pour affirmer cette fatalité des fuites mémoire. Dans certains cas critiques ce problème peut se poser mais c'est excessif d'en faire une généralisation . Toutes les applications ne sont pas muti-threads avec exploitation de mémoire partagée. Avec Internet l"accès aux ports peut aussi poser problème. Il n'y a pas que cette histoire de mémoire en C qui résume les problèmes de sécurité des logiciels.
Rust?
Jamais entendu parler ! Je dois être trop vieux. Parlez moi en assembleur, en COBOL, en FORTRAN, en C, en C++, en LISP, en Python, en JAVA,... mais Rust? Connais pas...
Il me semble que l'on peut distinguer dans les fuites mémoire et autres celles qui sont liées directement à la
programmation d'un système d'exploitation de celles qui résultent du développement d'applications sur ce système.
Dans ce dernier cas il n'y a pas de fatalité aux fuites mémoire, c'est une question d'écriture du code. Ces cas mis en
avant de vulnérabilités ou de comportements instables restent marginaux .
Le développement d'une application peut être le résultat d'une succession de développeurs dont les pratiques coïncident mal.
Et qui induisent des bogues.
Aucun intérêt à répéter sans cesse fuite mémoire pour mettre en avant Rust.
Maintenant si le niveau d'acuité des développeurs baisse alors oui mettre un garde fou comme Rust.
Mais à priori il n'y a aucune raison pour que ceux-ci écrivent des aberrations.
Peut-être que la Maison Blanche ait peur que les Russes ou les Chinois corrompent les logiciels de la défense ou autres secteurs stratégiques .
Il ne vous a pas échappé qu'une majorité d'applications en C++ et C tournent sans problème majeur même si le cycle des mises à jour
produit du code nouveau.
Peut être que la Maison Blanche ait peur que les Russes ou les Chinois corrompent les logiciels des secteurs sensibles aux Etats-Unis ?
Attention de ne pas confondre les fuites mémoire et les erreurs de sureté mémoire.
Les fuites mémoires sont gênantes car elles entrainent une surutilisation des ressources, mais elles ne sont pas un risque de sécurité important car leur comportement reste parfaitement défini. Au pire elles peuvent servir à provoquer un déni de service (ralentissement, crash), mais ça ne permet pas de détourner le fonctionnement de l'application pour en prendre le contrôle ou en extraire des donnée sensibles.
Les problèmes de sureté mémoire découlent d'une utilisation invalide de la mémoire (dépassement de buffer, accès mémoire non allouée, accès à des données non initialisées, ...) qui provoque un comportement indéfini. Ce comportement indéfini pouvant être exploité pour détourner l'application de son fonctionnement normal.
Si l’exigence de sécurisation de vos logiciels n'est pas particulièrement élevée, peut-être, mais sinon les erreurs mémoire ne sont absolument pas à négliger.
La grande majorité des failles de sécurité que l'on trouve dans les logiciels en C et C++ sont la conséquence d'erreurs mémoire.
Pour le coup, tout le monde est d'accord pour dire que le problème se produit suite à une erreur de programmation, donc c'est un facteur humain. Maintenant, la question est "qu'est ce qu'on fait pour éviter ça", parce qu'avoir un coupable ne résout pas le problème.
On pourrait dire qu'il suffit d'avoir des gens compétents et bien formé, mais on sait bien que dans la pratique les équipes seront toujours imparfaites, les développeurs parfaitement adaptés ne poussent pas dans les arbres, et même les meilleurs font parfois des erreurs. On trouve des problèmes de sécurité mémoire même dans des grosses équipes d'experts.
L'avantage de Rust est de garantir que les différents développeurs appliqueront sans erreur toutes des bonnes pratiques qui garantissent un code sans problème de sécurité mémoire, et ce, même s'ils ne maitrisent pas encore tout le projet ou s'ils ne sont pas bien concentrés parce qu'ils sont dans un mauvais jour.
Ça à d'autant moins d’intérêt que Rust ne garantit absolument pas l'absence de fuites, même si il limite pas mal le risque comparé au C. Rust protège surtout complètement contre les erreurs de sureté mémoire.
Et c'est vrai que Rust a bien d'autres qualités que la sureté mémoire, mais ça n'est pas le sujet de la discussion.
Je n'ai pas l'impression que, à expérience égale, le niveau des développeurs ait baissé ces vingt dernières années. Au niveau de la sécurité, je dirais même qu'ils sont globalement plus au courant des problématiques.
Par contre c'est le niveau de sécurité attendu par les clients qui augmente, ainsi que l'efficacité de pirates. Les Black Hat comme les White Hat sont beaucoup plus nombreux et avec des méthodologies toujours plus au points.
Le "sans problème majeur" est plus que discutable. On a régulièrement des patchs qui sortent en catastrophe pour corriger des vulnérabilités déjà exploitées.
Tout le monde n'a pas les mêmes exigence en sécurité, mais les attentes sont plutôt à la hausse maintenant que l'informatique est de plus en plus partout.
Vous pouvez oublier le "peut-être". On sait déjà que les grandes nations on des programmes d'exploitation de failles de sécurité et il y a mêmes des société privées qui vendent leurs service pour cela.
Sécuriser par la conception : Le point de vue de Google sur la sécurité de la mémoire
Existe-t-il un consensus au sein de l'industrie sur l'abandon de C/C++ ? Sécuriser par la conception : Le point de vue de Google sur la sécurité de la mémoire
Dans un livre blanc, Google partage son point de vue sur la sécurité de la mémoire. Voici les raisons pour lesquelles Google publie ce livre blanc.
Le projet zéro de Google indique que les vulnérabilités liées à la sécurité de la mémoire - défauts de sécurité causés par de subtiles erreurs de codage liées à la manière dont un programme accède à la mémoire - ont été "la norme pour attaquer les logiciels au cours des dernières décennies et c'est toujours la manière dont les attaquants réussissent". Leur analyse montre que deux tiers des exploits "0-day" détectés dans la nature utilisent des vulnérabilités liées à la corruption de la mémoire. Malgré des investissements substantiels pour améliorer les langages peu sûrs pour la mémoire, ces vulnérabilités continuent de figurer en tête des classes de vulnérabilités les plus couramment exploitées.
Dans ce document, Google examine les données, les défis liés à la sécurité de la mémoire, et discute des approches possibles pour atteindre la sécurité de la mémoire et leurs compromis. Elle y souligne également son engagement à mettre en œuvre plusieurs des solutions décrites dans le livre blanc, tout récemment avec une subvention de 1 000 000 dollars à la Rust Foundation, faisant ainsi progresser le développement d'un écosystème robuste de sécurité de la mémoire.
Pourquoi Google publie ce livre blanc maintenant ?
L'année 2022 a marqué le 50e anniversaire des vulnérabilités en matière de sécurité de la mémoire. Depuis lors, les risques liés à la sécurité de la mémoire sont devenus plus évidents. Comme d'autres, les données et recherches internes de Google sur les vulnérabilités montrent que les bogues liés à la sécurité de la mémoire sont très répandus et constituent l'une des principales causes de vulnérabilités dans les bases de code non sécurisées en termes de mémoire. Ces vulnérabilités mettent en danger les utilisateurs finaux, l'industrie et la société dans son ensemble. Google est encouragé par le fait que les gouvernements prennent également ce problème au sérieux, comme l'a montré la publication d'un document sur le sujet la semaine dernière par l'Office of the National Cyber Director (bureau du directeur national du cyberespace) des États-Unis.
Google :
En partageant nos idées et nos expériences, nous espérons inciter l'ensemble de la communauté et de l'industrie à adopter des pratiques et des technologies sans danger pour la mémoire, ce qui, en fin de compte, rendra la technologie plus sûre.
Le point de vue de Google
Chez Google, ils ont des dizaines d'années d'expérience dans la résolution, à grande échelle, de grandes catégories de vulnérabilités qui étaient autrefois aussi répandues que les problèmes de sécurité de la mémoire. Leur approche, qu'ils appellent "Safe Coding", traite les constructions de codage sujettes à la vulnérabilité comme des dangers (c'est-à-dire indépendamment et en plus de la vulnérabilité qu'elles peuvent causer), et est centrée sur l'assurance que les développeurs ne rencontrent pas de tels dangers lors de leurs pratiques de codage régulières.
Sur la base de cette expérience, ils pensent qu'une sécurité élevée de la mémoire ne peut être obtenue que par une approche de conception sécurisée centrée sur l'adoption complète de langages offrant des garanties rigoureuses en matière de sécurité de la mémoire. Par conséquent, ils envisagent une transition progressive vers des langages à sécurité mémoire tels que Java, Go et Rust.
Au cours des dernières décennies, outre les vastes bases de code à mémoire sécurisée de Java et Go, Google a développé et accumulé des centaines de millions de lignes de code C++ qui sont utilisées activement et font l'objet d'un développement actif et continu. Cette très grande base de code existante pose des problèmes importants pour la transition vers la sécurité de la mémoire.
Mais Google considère qu'il est important de compléter la transition vers des langages à mémoire sûre pour le nouveau code et les composants particulièrement à risque par des améliorations de la sécurité du code C++ existant, dans la mesure du possible. Ils pensent également que des améliorations substantielles peuvent être obtenues par une transition progressive vers un sous-ensemble de langage C++ partiellement sûr en mémoire, complété par des fonctions de sécurité matérielle lorsqu'elles sont disponibles.Google :
Nous ne voyons pas de voie réaliste pour une évolution du C++ vers un langage offrant des garanties rigoureuses de sécurité de la mémoire, y compris la sécurité temporelle. Une réécriture à grande échelle de tout le code C++ existant dans un langage différent, sûr pour la mémoire, semble très difficile et restera probablement impraticable.
Les investissements de Google dans les langages à mémoire sécurisée
Google reconnait que les langages à mémoire sécurisée ne résoudront pas tous les bogues de sécurité, mais tout comme ses efforts pour éliminer les attaques XSS par le biais d'outils l'ont montré, l'élimination de grandes catégories d'exploits profite directement aux consommateurs de logiciels et leur permet de se concentrer sur la résolution d'autres catégories de vulnérabilités de sécurité.Google :
Nous investissons activement dans de nombreuses solutions décrites dans notre livre blanc et dans notre réponse à la demande de renseignements du gouvernement fédéral américain sur la sécurité des logiciels open source.
- Android a écrit plusieurs composants en Rust au cours des dernières années, ce qui a permis d'améliorer considérablement la sécurité. Dans le module UWB (Ultra-wideband) d'Android, cela a permis d'améliorer la sécurité du module tout en réduisant l'utilisation de la mémoire et les appels interprocéduraux.
- Chrome a commencé à livrer certaines fonctionnalités en Rust ; dans un cas, Chrome a pu sortir son générateur de code QR d'une sandbox en adoptant une nouvelle bibliothèque à mémoire sécurisée écrite en Rust, ce qui a permis d'améliorer à la fois la sécurité et les performances.
- Google a récemment annoncé l'octroi d'une subvention d'un million de dollars à la fondation Rust afin d'améliorer l'interopérabilité avec le code C++. Cela facilitera l'adoption progressive de Rust dans les bases de code existantes où la mémoire n'est pas sûre, ce qui sera essentiel pour permettre à un plus grand nombre de nouveaux développements de se produire dans un langage à mémoire sûre. Dans le même ordre d'idées, nous nous efforçons également de résoudre les attaques inter-langues qui peuvent se produire lorsque l'on mélange Rust et C++ dans le même binaire.
- Google investit dans la construction d'un écosystème open-source à mémoire sécurisée par l'intermédiaire du GISR Prossimo et du projet Alpha-Omega de l'OpenSSF. En 2021, nous avons financé les efforts visant à intégrer Rust au noyau Linux, ce qui nous permet désormais d'écrire des pilotes à mémoire sécurisée. Ce financement est également destiné à fournir des alternatives ou des mises à jour de bibliothèques open-source clés dans un langage à mémoire sécurisée, comme la fourniture d'une implémentation TLS à mémoire sécurisée.
Source : Sécuriser par la conception : compléter la transition vers des langages à mémoire sûre par des améliorations de la sécurité du code C++ existant, selon Google
Et vous ?
Pensez-vous que cet avis de Google est crédible ou pertinent ?
Voir aussi :
Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités
Crédible ? Hem ! C'est quand même Google ! Le million de dollars donné à l'équipe Rust pour faciliter la migration parle bien. Qu'ils aient raison ou tort, ils entérinent la mort de C++ sur toutes les plateformes où Rust est implémenté. Donc il est deux fois crédible, d'une part, il est Google, d'autre part, il paye pour aider à faire le job.[B][SIZE=4]
Mon avis, je l'ai déjà donné plus haut. C gardera l'immense marché du petit embarqué. C++ est sur le barbecue.
Pour une application desktop, vu l'évolution de Java, C# est la première option à considérer. L'écriture d'un gros projet en full C++ a toujours été un choix inexplicable selon moi. Les bugs sont très méchants, les temps de dev sont monstrueux.
Pour du temps réel vraiment pointu comme un séquenceur audio (DAW) par exemple, le choix est plus difficile même si les machines d'aujourd'hui propulsent un programme javascript beaucoup plus vite que le même programme en assembleur d'il y a 20 ans. Il reste des problèmes de milliseconde qui peuvent se poser typiquement à la lecture d'une séquence musicale sur 20 pistes utilisant une demi douzaine d'instruments VST différents. Le minimum de synchronicité dans ce cas est d'au moins 5 ms. Un délai à la portée de langages de haut niveau avec un CPU récent quoique on puisse souhaiter descendre plus bas et employer Rust comme une bibliothèque pour améliorer la "résolution temporelle" (subtilement différente de la vitesse d'exécution)
D'autre part, dans les hackatons (CodinGame) les modules C++ tombent comme des mouches à chaque upgrade du compilateur. Très peu de modules survivent à 3 ou 4 upgrades (certains y parviennent quand même). C++ est quand même ultra sensible aux mises à jour.
A voir si le software des géants (office, .net framework, chrome, etc...) fera sa mue. Les grands éditeurs en ont les moyens. Je dirais même qu'ils y ont intérêt.
A voir aussi combien d'éditeurs moyens ne pourront pas faire face et mettront la clé sous la porte.
Il est évident que développeur Rust est une situation plus enviable que développeur C++ depuis quelques mois.
Rust a gagné tous les suffrages de toutes façons. Il semble évident que le marché l'adopte massivement à l'avenir.
Que je commence à en avoir marre de cette polémique stérile est inutile.
Chaque langage à ses qualités et ses inconvénients, surtout chez les langages de bas-niveau. Si Rust s'impose pour les domaines où la sécurité est la plus importante, tant mieux.
Mais je ne voit pas pourquoi des langages ayant des qualités largement confirmés comme le C et le C++ disparaîtrait.
Par contre je ne serait pas contre un débat sur la pertinence de certains langages de haut-niveau utilisés à tord et à travers... Avec des performances de plus en plus catastrophiques.
Tu penses à Python ou Ruby ?
J’aime beaucoup cet article : http://blog.gmarceau.qc.ca/2009/05/s...ty-of.html?m=1
Il classe les langages selon deux axes : vitesses d’exécution et concision des contributions au benchmarks (l’avantage d’un langage de haut niveau est logiquement d’être concis).
Aprés, un benchmarking doit être analysé avec prudence. Quand je vois des contributions C à un benchmark bien connu hyper optimisées à coup d’instructions MMX ou SSE2 donc non portable et non représentatif de ce que l’on coderait usuellement…
On y trouve que l’on peut avoir une concision proche de Python mais avec des langages de haut plus rapides. J’avoue avoir un faible pour les langages à typage fort et statiques (cela détecte pas mal d’erreurs à la compilation) mais à inférence de type qui fait que dans beaucoup de cas, on programme un peu comme avec un typage dynamique.
Heureusement que google est la pour sécuriser le code (écrit en C) du micro contrôleurde mon vibromasseurde ma télécommande.
L'intention est louable.
Dommage que la propagande Google (Rust) s'immisce dans l'équation.
Je vois pas trop le rapport : Rust est un projet libre, initialement créé par Mozilla, et maintenant géré par une fondation indépendante. Google utilise certes Rust dans certains composants d'Android, mais il n'a pas fait de propagande particulière pour Rust, contrairement à ce qu'il a pu faire pour ses langages maison : Go et surtout Dart.
Il faut voir que la généralisation de l'usage de Rust ne profite pas plus à Google qu'à ses concurrents. Il participe au financement de son infrastructure et de son évolution via des contributions à la Fondation, mais tout comme d'autres grand noms qui utilisent Rust (Amazon, Meta, Microsoft, ...). Il n'en retirent pas d'avantage concurrentiel particulier. Au contraire, si Google voulait que son investissement lui soit profitable, il aurait intérêt que les autres n'utilisent pas Rust, pour être le seul à profiter des améliorations qu'il contribue à financer.
C'est une question de SI. La robustesse en matière de sécurité du code informatique promet la SI.
Donc c'est normale que la maison Blanche s'intéresse à la programmation
Répondre avec citation
Partager