Microsoft se penche sur le langage Rust pour sa programmation système

Microsoft se penche sur le langage Rust pour sa programmation système

Les vieux pots

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

26/07/2019 10 minutes
67

Microsoft se penche sur le langage Rust pour sa programmation système

Microsoft considère très sérieusement le Rust comme successeur aux C et C++ pour sa propre programmation système. Une déclaration importante, qui jette une nouvelle lumière sur le langage créé par Mozilla et veut sensibiliser les développeurs aux problèmes de sécurité liés à la mémoire.

La firme s’est lancée dans une série d’articles portant sur la sécurité du code informatique. L’éditeur en dresse un tableau peu reluisant, avec un objectif en tête : réduire, et si possible se débarrasser des erreurs liées à la gestion de la mémoire.

Le constat s’établit sur la base de plusieurs études et d’une longue série de statistiques. Conséquence, la question se pose : par quoi remplacer les langages C et C++ couramment utilisés pour l’écriture du code natif ?

Les langages dits « memory safe » existent depuis longtemps. Microsoft donne bien sûr les exemples maison – C# et F# – on citera aussi l’un des plus connus : Java. Mais l’éditeur, même en citant leurs qualités intrinsèques, ne semble pas satisfait, pour une raison principale : leur coût en performances.

Il se tourne donc vers un langage open source créé par Mozilla, initialement pour ses propres besoins : Rust. Ce n’est plus vraiment un jeune langage (2010), mais il reste récent, posant des problématiques que nous exposerons. En dépit des défauts inhérents à son âge, l’entreprise s’intéresse de très près au Rust comme successeur de C/C++ dans ses propres produits, jusqu’à citer indirectement le noyau de Windows.

70 % des failles de sécurité liées à la mémoire

Dans une présentation donnée à la conférence BlueHat IL, Matt Miller, du MSRC (Microsoft Security Response Center), faisait un drôle de constat : l’immense majorité (70 %) des failles corrigées par Microsoft – et pour lesquelles une identification CVE avait été fournie – provenaient de bugs de corruption de mémoire introduits dans le code C ou C++ par les développeurs. Cette statistique s’est avérée stable sur la décennie écoulée.

Exemple le plus courant, très souvent croisé dans les comptes rendus de sécurité ? Les dépassements de mémoire tampon (buffer overflows). Ils surviennent quand un processus, censé écrire dans un espace mémoire spécifique, écrit dans un autre. Si ce dernier n’est pas libre, des données sont écrasées, pouvant entrainer un comportement imprévisible de l’ensemble du système.

Dans la plupart des cas, le symptôme est un plantage de l’application ou du système. Mais un dépassement de mémoire tampon peut aussi être détourné et utilisé à des fins de piratage informatique. La technique consiste alors à écrire dans une zone un code exécutable.

Notez tout de même que ces soucis sont connus depuis bien longtemps. C’est ce qui explique l’apparition de technologies comme l’ASLR (Adress Space Layout Randomization). Le principe en est simple : déplacer de manière aléatoire les données critiques pour que leur emplacement soit imprévisible. Ces techniques ne sont toutefois pas infaillibles et ne font que limiter les risques, sans jamais les réduire à zéro.

Les langages « memory safe »

Ces fautes sont courantes en C et C++ car ils n’incluent pas dès l’origine de mécanismes de sûreté pour la mémoire. Les pointeurs utilisés peuvent cibler n’importe quelle zone mémoire et requièrent donc de multiples précautions, reposant sur les épaules des développeurs.

« Le boulot principal d’un développeur n’est pas de se préoccuper de la sécurité mais de travailler sur les fonctionnalités », explique Gavin Thomas, ingénieur responsable au MSRC. « Plutôt que d’investir dans toujours plus d’outils, formations et correctifs, pourquoi pas dès le départ un langage où ils ne pourraient pas introduire de problèmes de sûreté mémoire dans leurs fonctionnalités ? ».

C’est déjà le cas de langages comme C# ou Java qui sont de haut niveau, c’est-à-dire centrés sur la résolution de problèmes spécifiques, sans se soucier (en général) des composants de la machine. Parmi leurs caractéristiques, on trouve en particulier le typage sûr. Le compilateur valide alors (statiquement) les types en vérifiant qu’ils n’ont pas été affectés de manière erronée. Cet attribut permet à lui seul d’éviter la plupart des erreurs menant à une corruption de la mémoire.

Mais ils ont un désavantage : ils requièrent la présence d’un runtime pour fonctionner. Cette machine virtuelle a un coût en performances, pas nécessairement visible dans un cadre applicatif (potentiellement au lancement, souvent un peu plus long), mais clairement plus sensible pour un système d’exploitation, a fortiori un noyau.

C et C++ restent donc largement utilisés pour leurs performances. On se souvient que Google avait même lancé son NaCl (Native Client) pour permettre aux développeurs web d’écrire du code C/C++, chargé avec le reste du site. Principal bénéfice, la rapidité d’exécution. Le projet a depuis été supplanté par les nombreux travaux sur WebAssembly, autour duquel s’est organisé un consortium (voir notre article).

Le C++ en particulier n’est pas démuni contre les éventuels soucis de corruption de la mémoire. Plusieurs mesures ont été implémentées avec les années. Par exemple, les pointeurs intelligents peuvent prévenir en partie les risques. Cependant, même si un développeur au meilleur de sa forme et avec les bonnes compétences peut faire attention à toujours utiliser les techniques à sa disposition, la difficulté devient exponentielle quand le projet prend une taille importante.

Ce qu’aimerait Microsoft ? La synthèse de ces avantages : « Si seulement les développeurs pouvaient avoir toutes les garanties de sécurité pour la mémoire des langages comme C# combinées à toute l’efficacité de C++ ». C’est là qu’intervient le Rust, qui pour l’éditeur réunit le meilleur des deux mondes.

La solution dans l’open source

Le simple fait de regarder en direction du langage de Mozilla n’est pas anodin : le Rust est open source (licence Apache 2.0). Microsoft le considère-t-il sérieusement comme une solution d’avenir pour ses propres besoins ? Il semblerait bien.

Dans son dernier billet de blog, l’éditeur évoque les langages « memory safe » comme C#, F#, Swift, Go et Python. Aucun d’entre eux ne se veut universel et est donc à utiliser en fonction du contexte. Python est par exemple un langage de script et n’est pas fait pour la situation qui intéresse Microsoft.

« Nous discutons cependant du besoin d’un langage sûr pour la programmation système (un langage pouvant construire des systèmes sur lesquels d’autres logiciels vont fonctionner, comme un noyau). De telles charges de travail nécessitent la vitesse et les performances prévisibles que C, C++ et Rust fournissent. Les langages capables d’assurer la sûreté de la mémoire via le ramasse-miettes ne sont pas idéaux puisque leurs runtimes peuvent conduire à des performances imprévisibles et une surcharge inutile ».

Parmi les avantages du Rust, Microsoft cite en particulier son runtime minimal et surtout optionnel. La bibliothèque standard dépend de libc (comme C et C++), mais n’est pas forcément nécessaire, permettant au code de fonctionner sans système d’exploitation préalable.

Deuxième avantage, la granularité dans le contrôle de la mémoire, qui permet au développeur « de choisir quand et combien de mémoire doit être allouée ». Sur ce point, Microsoft considère que Rust est au même niveau que C et C++.

Mais c’est bien sur la protection de cette mémoire que Rust se différencie, faisant dire à l’entreprise que les fameux 70 % de failles n’auraient sans doute jamais existé si le code concerné avait été écrit avec le langage de Mozilla. À noter, d’ailleurs, que Microsoft ne s’exclue pas des erreurs, puisqu’il s’agit dans l’immense majorité des cas de vulnérabilités relevées dans ses propres produits.

La protection accordée n’est cependant pas forcée. Les développeurs peuvent déclarer explicitement des blocs de code comme « unsafe » quand les opérations l’exigent. Mais même ces opérations finissent par être « empaquetées » dans des structures vérifiées statiquement à la compilation.

D’autres points sont appréciés. L’exactitude du langage par exemple, qui a permis en interne de vérifier un vieil adage : « Si ça compile, c’est que ça marche ». La vérification statique des propriétés va également au-delà de la mémoire et permet de se débarrasser d’autres problèmes potentiels, comme les pointeurs null et les accès concurrents.

C’est toutefois la communauté qui remporte l’adhésion de Microsoft. Même si le langage a été créé par Mozilla, qui investit toujours dedans, la majorité des contributions provient de sa communauté. Selon le classement Stack Overflow pour l’année 2018, Rust est en fait le langage le plus populaire, devançant Kotlin, Python et TypeScript. Et plus la communauté grandit, plus le langage devient apte à répondre aux demandes, et plus les tests sont nombreux.

Et pourquoi pas un Windows réécrit en Rust ?

Quelle crédibilité apporter aux réflexions de Microsoft sur ce langage ? Conséquente car l’éditeur en est à publier plusieurs billets de blogs expliquant tout le bien qu’il pense de Rust et la manière dont il pourrait très clairement bénéficier à la programmation système. Et puisque les fameux 70 % concernent des failles dans ses propres produits, il est permis de penser que l’entreprise pense avant tout à sa propre programmation système.

L’image d’un avenir réécrit en Rust chez Microsoft se précise encore quand la firme aborde les quelques points noirs qui l’empêchent pour l’instant de se mettre à la tâche. Parmi eux, un manque d’interopérabilité avec la chaine d’outils maison. L’interopérabilité avec le C++ est également citée comme un problème, de même que la manière de réguler l’utilisation du surensemble « unsafe » du Rust dans les projets de grande taille.

Microsoft va donc continuer à publier des billets sur le langage, notamment pour détailler les problèmes et ce qui manque à son goût pour une utilisation à grande échelle au sein de l’entreprise. La couleur est d’ailleurs annoncée : elle espère impliquer la communauté Rust pour réfléchir aux solutions, signe supplémentaire d’une volonté d’utiliser le langage.

Dans l’hypothèse où toutes les barrières seraient levées, faut-il s’attendre à une réécriture de Windows en Rust ? Pas nécessairement. Au vu de l’ampleur du travail, il est plus probable que la firme travaillerait directement sur de nouvelles briques ou une nouvelle génération de son système d’exploitation.

En attendant, le langage va probablement bénéficier de ce nouvel éclairage, de la même manière que TypeScript (créé par Microsoft) avait été adoubé par Google, qui en avait fait la voie royale pour Angular.

67

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

70 % des failles de sécurité liées à la mémoire

Les langages « memory safe »

La solution dans l’open source

Et pourquoi pas un Windows réécrit en Rust ?

Commentaires (67)


Tiens, MS nous ressort donc les idées de son vieux projet de R&D Singularity du placard. Pourquoi pas, ce n’est pas inintéressant de tester ce genre d’idée et ils ont justement les moyen de le faire.


En espérant qu’ils fassent de gros dons à Mozilla…




C’est déjà le cas de langages comme C# ou Java qui sont de haut niveau, c’est-à-dire centrés sur la résolution de problèmes spécifiques, sans se soucier (en général) des composants de la machine.



Ce qui est aussi son principal défaut quand on a des gros volumes de données à traiter, la conso mémoire joue parfois des tours.

J’avais eu le soucis avec des applis en 32 bits ou je devais loader et recouper des fichiers de 4 à 5 go et que je me retrouvais avec la mémoire pleine du fait que le GC n’avais pas envie de passer quand il le fallait :(



Je ne connais pas spécialement Rust, mais si Crosoft se penche sur un langage qui pourrait remplacer le C++ en ajoutant de la sécurisation mémoire, ca ne serait pas un mal je suivrais ça <img data-src=" />


Je ne connaissais rust que de nom et ne me suis pas du tout penché sur le langage.

Un tel article me fait dire qu’il me faudrait en fait clairement le faire. <img data-src=" />



M’en vais donc voir un peu le langage et les framework facilement intégrables avec. :)








marba a écrit :



En espérant qu’ils fassent de gros dons à Mozilla…





On peut pas reproché à Microsoft de ne pas investir ces dernières années dans les projets Open-Source. Donc qu’ils fassent des dons ou qu’il contribue eux même au développement du langage ça sera profitable pour tout le monde. Voir la deuxième option me plait presque plus, si plusieurs grosses entreprises se fédère autour de Rust pour en faire le langage principal de la prog’ system dans les années futures je serais pas contre :).



Ce qui est aussi intéressant avec Rust est que l’on peut l’ “interfacer” avec du code C++.



Cela permet de garder la majorité du code en C++ mais qu’une nouvelle fonctionnalité ou une mise à jour d’une partie du code peut elle être refaite en Rust sans tout réécrire d’un coup.


C’est dans ce cas là que j’aime savoir comment fonctionne la gestion de la mémoire et du Garbage collector. A un certain moment, on ne peut pas ignorer quelque fonctionnement du langage (surtout dans ton cas où tu utilisent de gros volume de donnée).



Souvent par exemple, les objets qui n’ont eu d’existence que dans une fonction sont systématiquement supprimer à la fin de la fonction (ça correspondrait à la pile dans C/C++).



Parfois il y a aussi les “smart pointer” (python en utilise) qui compte le nombre de fois vers lequel on pointe sur l’objet et dès lors que le compteur tombe à zero, on supprime. Cependant du coup ce genre d’outil n’aime pas (mais alors vraiment pas) les références cycliques (un objet A a un pointeur vers un objet B, et l’objet B a un pointeur vers l’objet A). Ce genre de référence cyclique peut être utile par exemple dans les structures de données donnant la possibilité d’un retour arrière (double linked list en java, mais aussi l’arbre du DOM qui permet aussi bien d’aller cherche chercher des nœuds enfants que revenir au parent). Du coup, dans le cadre de smart pointer, mettre un pointer à Null/None n’est pas aberrant, ça force sa suppression systématique (c’est une façon safe de faire un ‘free/del’) à l’instant même (et pas à la fin de la fonction, quand le smart pointer sera détruit).


Les langages dits «&nbsp;memory safe&nbsp;» existent depuis longtemps. Microsoft donne bien sûr les exemples maison – C# et F# – on citera aussi l’un des plus connus&nbsp;: Java



Oui bon. C’est plutôt aux programmeurs d’arrêter de faire des choses pas propres.



C’est un peu comme cette époque ou pas mal de glands répétaient à tue tête que PHP n’était pas “sécure”. Alors qu’il était au delà de tout doute que c’était plutôt des problèmes Apache, de configuration serveur et bien sur de programmeurs qu’on pourrait qualifier de pigiste.

&nbsp;

Il serait bon de préciser que la politique EEE (Embrace, Enhance Extinguish) de Microsoft commence comme cela.



&nbsp;


Non, le langage est un outil, par une finalité. S’il existe des outils plus adaptés et qui entraînent moins d’erreurs, il faut les adopter. Le travail d’un développeur c’est de faire des fonctionnalités utiles, pas de passer du temps à gérer de la sécurité de bas niveau.

Et c’est d’autant plus vrai si le nouvel outil n’entraîne aucun désavantage en termes de performance par exemple.



Personne ne code “pour la beauté du code”. Et de toutes façons il n’y a rien de beau dans le C et le C++


Oui et j’ajoute que personne n’est infaillible, même les meilleurs développeurs peuvent avoir un coup de mou un jour et se planter. Si les langages peuvent aider à plus de sécurité, c’est à prendre, surtout dans le cas de rust où ce n’est pas compromettant pour les perfs.



D’autant que ce n’est pas ici juste une lubie de hipster, ça part d’un constat très concret (et négatif) sur les correctifs de sécurité, donc ce n’est ni plus ni moins que du pragmatisme.



Pour avoir essayé rust, c’est un langage très rigoureux à la compilation … ce qui peut donner quelques crises d’arrachage de cheveux à l’écriture, mais la récompense est toujours au bout du chemin, comme dit l’article, quand ça compile, ça marche.


Principe de la loi de Murphy, s’il y a la possibilité de faire quelque chose mal, il y aura toujours quelqu’un pour le faire. Or développer en C et C++ c’est jouer au foot dans un champs de mine : il y a des pièges partout et tu va forcément sauter pied joint sur l’un d’entre eux.

Tout ce qui ont déjà un jours touché à C ont fait l’expérience du pointeur dont l’espace mémoire pointé venait d’être réaffecté d’une manière ou d’une autre (le classique du débutant : la fonction qui retourne un array créer en tant que variable local).

Encore en C, tu es par exemple obliger de “caster” à la mains les pointeurs si tu veux utiliser un peu de généricité. Or, caster à la main, c’est clairement une opération “unsafe”.









ErGo_404 a écrit :



Personne ne code “pour la beauté du code”. Et de toutes façons il n’y a rien de beau dans le C et le C++







C++, c’est simple, tous ceux qui ont touché ce langage n’en sont jamais véritablement sortis indemnes. Bjarne Stroustrup doit être un alias pour Abdul Alhazred.









tazvld a écrit :



Principe de la loi de Murphy, s’il y a la possibilité de faire quelque chose mal, il y aura toujours quelqu’un pour le faire. Or développer en C et C++ c’est jouer au foot dans un champs de mine : il y a des pièges partout et tu va forcément sauter pied joint sur l’un d’entre eux.

Tout ce qui ont déjà un jours touché à C ont fait l’expérience du pointeur dont l’espace mémoire pointé venait d’être réaffecté d’une manière ou d’une autre (le classique du débutant : la fonction qui retourne un array créer en tant que variable local).

Encore en C, tu es par exemple obliger de “caster” à la mains les pointeurs si tu veux utiliser un peu de généricité. Or, caster à la main, c’est clairement une opération “unsafe”.







C++, c’est simple, tous ceux qui ont touché ce langage n’en sont jamais véritablement sortis indemnes. Bjarne Stroustrup doit être un alias pour Abdul Alhazred.





Je ne peux qu’adhérer complètement à ce commentaire.



Sinon pour le Rust, j’avais entendu dire que c’était cool, mais du coup je crois que je vais vraiment m’y intéresser. Surtout si crosoft se mets dedans, ça donne envie de se pencher sur le sujet









TheGuit a écrit :



On peut pas reproché à Microsoft de ne pas investir ces dernières années dans les projets Open-Source. Donc qu’ils fassent des dons ou qu’il contribue eux même au développement du langage ça sera profitable pour tout le monde. Voir la deuxième option me plait presque plus, si plusieurs grosses entreprises se fédère autour de Rust pour en faire le langage principal de la prog’ system dans les années futures je serais pas contre :).







Tant que Microsoft ne prend pas le lead sur le développement du langage pour tout flinguer, oui ça peut être positif.









ErGo_404 a écrit :



Non, le langage est un outil, par une finalité. S’il existe des outils plus adaptés et qui entraînent moins d’erreurs, il faut les adopter. Le travail d’un développeur c’est de faire des fonctionnalités utiles, pas de passer du temps à gérer de la sécurité de bas niveau.

Et c’est d’autant plus vrai si le nouvel outil n’entraîne aucun désavantage en termes de performance par exemple.



Personne ne code “pour la beauté du code”. Et de toutes façons il n’y a rien de beau dans le C et le C++





Non, le langage n’est que langage. Il favorise un paradigme/usage ou un autre, rien de plus. Le FrameWork (ou cadre de développement en bon français) est lui l’outil qui permet de ne plus refaire dix fois les choses ou de se défaire d’une complexité non désirée pour un type de projet ou un autre. On pourra aussi évoquer la standardisation du code.



&nbsp;



tazvld a écrit :



Principe de la loi de Murphy, s’il y a la possibilité de faire quelque chose mal, il y aura toujours quelqu’un pour le faire. Or développer en C et C++ c’est jouer au foot dans un champs de mine : il y a des pièges partout et tu va forcément sauter pied joint sur l’un d’entre eux.

Tout ce qui ont déjà un jours touché à C ont fait l’expérience du pointeur dont l’espace mémoire pointé venait d’être réaffecté d’une manière ou d’une autre (le classique du débutant : la fonction qui retourne un array créer en tant que variable local).

Encore en C, tu es par exemple obliger de “caster” à la mains les pointeurs si tu veux utiliser un peu de généricité. Or, caster à la main, c’est clairement une opération “unsafe”.







C’est valable pour tout, y compris Rust ou tout autre candidat. Il y a aura toujours un problème ou un autre dans tout les langages.&nbsp; Mais ce que tu décris est une erreur humaine. Ce n’est pas le langage qui fait la bêtise.

&nbsp;

&nbsp;Et puisqu’on parle de possibilités il est amusant de dire qu’un framework Rust pourrait lui aussi avoir un souci de sécurité à un autre niveau X ou Y et qu’on ne le verrait qu’après avoir tout migré. Ils auraient l’air fin les gus.



Donc bon. Je ne suis pas contre le changement mais vu le nombre de langages existant faire du changement pour changer sur ce seul argument me semble peut rationnel. Surtout si c’est pour passer sur moins performant au final.



Sans compter l’adaptation des applicatifs non Microsoft qu’il faudra faire. Ca risque de bousculer le marché. Hé oui qu’on le veuille ou non un nouvel environnement apporte des avantages et aussi des contraintes.



&nbsp;Migrer tout cela dans un langage “hype” est un gros travail mais surtout un travail dont on ne connaît pas la porté des problèmes. Ils ne seront décourvert que sur le moment comme bien souvent. Et des solutions pas forcément très “corporate” seront mise en place. Comme toujours. Une cible de migration qui n’aurait que des avantages n’existe pas.



&nbsp;Avec tout cela si on me disait qu’une grève de dévs chez Microsoft est en cours cela ne m’étonnerai guère. Passer sur Rust ca veut dire trouver de nouveaux programmeurs peut être plus jeunes donc plus dociles… Belle com’.

&nbsp;

&nbsp;



&nbsp;









NextInpact a écrit :



classement Stack Overflow





Dans les dreaded il y quand même HTML et CSS à plus de 44% ! Sérieusement?! Faut arrêter le dev alors <img data-src=" />









TexMex a écrit :



C’est valable pour tout, y compris Rust ou tout autre candidat. Il y a aura toujours un problème ou un autre dans tout les langages.  Mais ce que tu décris est une erreur humaine. Ce n’est pas le langage qui fait la bêtise.





Oui, Rust va aussi avoir ses dangers, mais il vient avec ses protections bébés qui fait en sorte que pour sauter par accident sur une mine, il a vraiment fallut y mettre de sa (mauvaise) volonté. Certain langage vont t’offrir plus ou moins de protection contre les pièges courant de programmation statistiquement, tu vas plus ou moins facilement faire des conneries.



Et pour citer Bjarne Stroustrup (principale responsable de C++):





Bjarne Stroustrup a écrit :



C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.







Ce n’est pourtant pas un mec incompétent dans le domaine, mais il considère que déjà, C, par design, est plein de pièges difficiles à tous les éviter.





Pour le reste de ce que tu raconte, c’est un projet de R&D. Le but n’est pas d’en faire absolument le prochain Windows avec ça. C’est de tester une idée. Voir où ça mène, voir ce que ça résout effectivement et quel sont les nouveaux problèmes que ça apporte… Au final, ça peut avoir une suite direct, mais généralement, de manière indirect, il y a des moyens que MS en tire des leçons.



Ce n’est pas nouveau, Microsoft avait déjà fait un projet de R&D sur l’utilisation d’un autre type de langage “plus sécurisé” que C et C++ pour faire un noyau. Le projet “Singularity” était ainsi un noyau entièrement réalisé dans le langage manager C#. Lui même a eu des prédécesseur, ce n’est pas une idée nouvelle (j’ai vu JavaOS) mais le noyau de Windows10 n’a pas pour autant changer, c’est toujours le bon vieux Windows NT qui date de 1993 écrit en C,C++ et assembleur et utilisé depuis Windows 2000 en tant que noyau pour l’OS de MS et ce n’est pas prêt de changer.



Les trolls gentils qui passent pas un vendredi, mais les SPAM de «sites de rencontre» dans les commentaires jamais supprimés (notamment les bons plans, regardez le dernier en date) .



Vous vous foutez de moi ?


Je vais me faire sworder aussi, mais un jour il faudrait songer à arrêter d’idéaliser Microsoft.


Il n’y a pas de troll gentil, le vendredi est un jour comme les autres, et si un spam est resté c’est que nous ne l’avons pas vu. Si tu en vois un, tu peux d’ailleurs le signaler, ça nous permet d’intervenir très rapidement. Parce&nbsp; - attention spoiler - ça ne nous fait pas spécialement rire non plus :)


Ce n’est pas un troll, une insulte ou du HS. Encore que je me demande qui ton commentaire visait.

&nbsp;


Ici, personne n’a idéalisé Microsoft. MS est une boite intéressante à suivre, qu’on l’aime ou pas. Et ici, c’est vraiment pertinent justement.



D’ailleurs, j’ai découvert ces blogs récemment et c’est toujours intéressant à lire quand on est développeur. Les sujets sont détaillés, explicités avec pas mal d’objectivité. Microsoft n’hésite pas à critiquer son propre travail, à chercher ailleurs pour trouver des idées.



Bel exemple, le blog sur le Terminal, qui offre un historique des consoles (UNIX, Windows), les avantages et inconvénients de chaque, les erreurs faites par MS à l’époque (avec le pourquoi) et comment ils se sont adaptés pour revenir dans le bon chemin (ce qui donne maintenant un Terminal open source, en UWP/Core).


Je vous les ai signalé plusieurs fois sans aucunes actions de votre part.




Mais c’est bien sur la protection de cette mémoire que Rust se différencie, faisant dire à l’entreprise que les fameux 70 % de failles n’auraient sans doute jamais existé si le code concerné avait été écrit avec le langage de Mozilla.











TexMex a écrit :



Donc bon. Je ne suis pas contre le changement mais vu le nombre de langages existant faire du changement pour changer sur ce seul argument me semble peut rationnel.







Oui la sécurité informatique ce n’est qu’un petit détail ces temps ci <img data-src=" />



Depuis le temps qu’on “maitrise” le C/C++, s’il était possible d’avoir des outils antifuite parfait, on les aurait. Si Microsoft envisage un autre langage/techno, c’est qu’il y a matière.



Et personne n’a dit que ce sera facile , sans problème ou je ne sais quoi. Microsoft affirme juste, preuve à l’appui, que “C/C++ c’est bien sympa mais apparemment on ne s’en sortira jamais, il faut évoluer.”. Et Rust est une piste.



Sans exagération ? Parce que ce sont des mails qu’on traite en priorité, ça et les erreurs signalées dans les actualités. D’autant que les comptes de spams sont atomisés en deux clics et que nous n’avons vraiment aucune raison raison de les garder, bien au contraire.








Vincent_H a écrit :



…D’autant que les comptes de spams sont atomisés en deux clics et…





&nbsp;Est-ce bien la meilleure solution ? On dirait que les spammeurs ne se lassent pas de créer des comptes.



On ne les supprime pas. Ils sont bloqués et les tous leurs comms sont supprimés. Les inscriptions sont faites manuellement, on ne peut pas vraiment lutter contre ça, mais on peut au moins les empêcher d’utiliser le même pseudo (maigre consolation).


Sans exagérations. C’est surtout dans les commentaires des bons plans que visiblement ils passent votre vigilance.


Tu peux m’en montrer un ?








tazvld a écrit :



Oui, Rust va aussi avoir ses dangers, mais il vient avec ses protections bébés qui fait en sorte que pour sauter par accident sur une mine, il a vraiment fallut y mettre de sa (mauvaise) volonté. Certain langage vont t’offrir plus ou moins de protection contre les pièges courant de programmation statistiquement, tu vas plus ou moins facilement faire des conneries.



Et pour citer Bjarne Stroustrup (principale responsable de C++):





Ce n’est pourtant pas un mec incompétent dans le domaine, mais il considère que déjà, C, par design, est plein de pièges difficiles à tous les éviter.





Pour le reste de ce que tu raconte, c’est un projet de R&D. Le but n’est pas d’en faire absolument le prochain Windows avec ça. C’est de tester une idée. Voir où ça mène, voir ce que ça résout effectivement et quel sont les nouveaux problèmes que ça apporte… Au final, ça peut avoir une suite direct, mais généralement, de manière indirect, il y a des moyens que MS en tire des leçons.



Ce n’est pas nouveau, Microsoft avait déjà fait un projet de R&D sur l’utilisation d’un autre type de langage “plus sécurisé” que C et C++ pour faire un noyau. Le projet “Singularity” était ainsi un noyau entièrement réalisé dans le langage manager C#. Lui même a eu des prédécesseur, ce n’est pas une idée nouvelle (j’ai vu JavaOS) mais le noyau de Windows10 n’a pas pour autant changer, c’est toujours le bon vieux Windows NT qui date de 1993 écrit en C,C++ et assembleur et utilisé depuis Windows 2000 en tant que noyau pour l’OS de MS et ce n’est pas prêt de changer.







Rien n’empêche de faire évoluer un langage et/ou son compilateur pour plus de robustesse. C’est peu être un processus lent et qui n’est pas sensible au doux souhait des éditeurs, mais ça reste possible.&nbsp; Là ou on nous sort (enfin ressort) l’idée que de changer de techno c’est éventuellement mieux. Avec comme accompagnement son quota de trolls correspondant. Je suppose que si tu peux citer ces choses de ton dernier paragraphe tu as du rencontrer aussi des “technos révolutionnaires” (las famosas) qui finalement ne font pas vraiment mieux qu’avant. Voire pire.



Il y a un problème dans le monde du logiciel c’est la politique des éditeurs qui, pour imposer leur produits (et donc dominer le marché) doivent séduire les programmeurs. Et plus ces derniers sont fourbis de sièges bébé plus ça leur plaît (plus ils sont crétins aussi). Cela fait baisser le niveau général de maîtrise des programmeurs. Au final ça coûtera moins cher à l’embauche.



&nbsp;Et on retombe dans le sempiternel “avec ce langage on peut tout faire”. et ensuite je cite : “on ne peut pas faire car la y’a pas de lib pour cela” sorti de la bouche de programmeurs areuh areuh qui ne fera jamais de lib.



L’histoire; bien malheureusement se répète.&nbsp;



&nbsp;



CryoGen a écrit :



Oui la sécurité informatique ce n’est qu’un petit détail ces temps ci <img data-src=" />



Depuis le temps qu’on “maitrise” le C/C++, s’il était possible d’avoir des outils antifuite parfait, on les aurait. Si Microsoft envisage un autre langage/techno, c’est qu’il y a matière.



Et personne n’a dit que ce sera facile , sans problème ou je ne sais quoi. Microsoft affirme juste, preuve à l’appui, que “C/C++ c’est bien sympa mais apparemment on ne s’en sortira jamais, il faut évoluer.”. Et Rust est une piste.







Je ne dis pas que cela n’est pas un sujet d’intérêt. Simplement que cette seule raison n’est pas suffisante. Au lieu d’améliorer les conditions de développement de l’existant à savoir :





  • Faire évoluer le langage/compilateur incriminé.

  • Adapter les méthodes (et ne plus faire de l’Agile en diagonale par exemple).

  • Mettre des neurones dans les programmeurs aussi.



    …on nous dit (enfin suggère subrepticement) qu’un autre langage est mieux. Oui cette “preuve” est bien fragile en fait. Donc sans montrer de garanties. C’est beau. Parce que bon, on a dit cela de plein de langages.



    &nbsp;Tu avances qu’il n’est pas possible d’avoir des outils antifuite pour le C/C++. C’est juste et c’est juste que ce n’est pas la vocation de ce langage. Si tu lis 6 valeurs dans ton tableau au lieux de 5 (et que dans ce segment mémoire il est permis de lire). Ce n’est pas la faute du langage. C’est la faute de la bêtise qui a fait faire au programmeur cette erreur. Car comme on le sait tous les programmeurs ne font pas d’erreur. Ils ajoutent de nouvelles fonctionnalités encore incomprises du public et des machines. Bref.

    &nbsp;

    &nbsp;Ici on nous fait passer l’idée que c’est mieux de passer à autre chose. C’est juste pas la première fois qu’on voit ça. C’est un peu re-lou à la fin.



    Il serait plus judicieux d’induire l’idée que l’on pourrait enrichir ces langages (ou les rendre plus flexibles) avec soit de nouvelles fonctionnalités ou soit des restrictions à la demande via une option de compilation par exemple. Techniquement parlant rien ne l’empêche. Seulement voila beaucoup n’en sont pas capable. Aussi l’éditeur dans se démarche n’y est pas favorable (dominer le marché, embaucher à peu de frais).



    &nbsp;Bref, l’herbe est plus verte ailleurs mais pas tant que cela.

    &nbsp;





    &nbsp;









Vincent_H a écrit :



Tu peux m’en montrer un ?







&nbsp;Pour aller dans son sens, j’en ai signalé pas mal de ce genre là. La photo de l’annonce qu’il pointe, je l’a déjà vu.



J’ai déjà vu des forum qui interdisaient la possibilité de poster des liens si on avait moins de 4 messages. Cela écrêmait un peu les bots.

Le problème de ce genre de SPAM c’est que l’on s’aperçoit vite des heures d’embauches ou de fin de travail des modérateurs.



On attend tes propositions d’amélioration pour le C++ , je pense que tu peux te faire un paquet de pognon.



Si c’était aussi simple, je pense que les ingé de Microsoft l’aurait fait. Comme tu le dit, changer de langage n’est pas une mince affaire, et pour des projets comme Windows ca coute du vblé rien que d’émettre l’idée <img data-src=" />


https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html



Je vois pas tellement l’intérêt de ta prose. On peut pas changer le design de C/C++, c’est pour ça qu’ils sont reparti de 0 en intégrant les contraintes de sécurité mémoire dans leur cahier des charges.



Le résultat est brillant, je ne comprends pas ta complainte.


Je n’ai pas lu tous les commentaires, la discussion est longue mais une nouveauté toute récente concernant l’interopérabilité C++/Rust, les dévs de Firefox ont réussi à faire du LTO (link-time optimization) entre fichiers objet issus de C++ et de Rust !!!

&nbsp;<img data-src=" />

https://www.reddit.com/r/cpp/comments/ch7g6n/mozilla_just_landed_crosslanguage_l…



C’est un peu le niveau ultime de l’interopérabilité quand même… Faut juste que Microsoft se mette à la page <img data-src=" />








TexMex a écrit :



C’est valable pour tout, y compris Rust ou tout autre candidat. Il y a aura toujours un problème ou un autre dans tout les langages.&nbsp; Mais ce que tu décris est une erreur humaine. Ce n’est pas le langage qui fait la bêtise. &nbsp;





&nbsp;En informatique, l’erreur humaine est juste un pléonasme. Toutes les erreurs sont forcément humaines. Améliorer la sécurité c’est simplement réduire les risques d’erreur humaine. Parce que crier à l’incompétence a posteriori, ça ne résout rien.



Un langage qui empêche tout simplement toute une famille d’erreurs critiques, c’est très intéressant. Surtout quand on sait que ces erreurs représentent plus des deux tiers des faille critiques, dans des logiciels qui ne sont pas écris pas des débutants.







TexMex a écrit :



Et puisqu’on parle de possibilités il est amusant de dire qu’un framework Rust pourrait lui aussi avoir un souci de sécurité à un autre niveau X ou Y et qu’on ne le verrait qu’après avoir tout migré. Ils auraient l’air fin les gus.



Donc bon. Je ne suis pas contre le changement mais vu le nombre de langages existant faire du changement pour changer sur ce seul argument me semble peut rationnel. Surtout si c’est pour passer sur moins performant au final.

&nbsp;

Sans compter l’adaptation des applicatifs non Microsoft qu’il faudra faire. Ca risque de bousculer le marché. Hé oui qu’on le veuille ou non un nouvel environnement apporte des avantages et aussi des contraintes.





Le problème c’est que dès qu’on parle de Rust, les gens qui font du C++ se sentent agressés comme si il y avait un grand complot qui visait à interdire définitivement tous les autres langages et de jeter l’intégralité de milliards de lignes de code existantes à la poubelle sous 15 jours pour tout réécrire tout en Rust, suite à quoi il se retrouveront définitivement au chômage.



Il n’en est absolument rien. Rust est surtout intéressant pour un projet neuf ou la réécriture d’une partie d’une application qui en avait de toute façon besoin. Même Mozilla qui a activement participé à la création de Rust utilise

encore beaucoup plus de C++ que de Rust dans son navigateur. I ont utilisé Rust que pour des parties de Firefox qui avaient besoin d’une réécriture de toute façon.

&nbsp;



TexMex a écrit :



Migrer tout cela dans un langage “hype” est un gros travail mais surtout un travail dont on ne connaît pas la porté des problèmes. Ils ne seront décourvert que sur le moment comme bien souvent. Et des solutions pas forcément très “corporate” seront mise en place. Comme toujours. Une cible de migration qui n’aurait que des avantages n’existe pas.



&nbsp;Avec tout cela si on me disait qu’une grève de dévs chez Microsoft est en cours cela ne m’étonnerai guère. Passer sur Rust ca veut dire trouver de nouveaux programmeurs peut être plus jeunes donc

plus dociles… Belle com’.





J’ai des collègues de plus de 50 ans qui apprennent de nouveaux langages. A t’entendre les développeurs C++ sont une espèce supérieure capable de tout comprendre et de ne jamais faire la moindre erreur. Je n’imagine pas une seule&nbsp; seconde que cette élite soit incapable d’apprendre à utiliser un langage différent.

&nbsp;



TexMex a écrit :



Rien n’empêche de faire évoluer un langage et/ou son compilateur pour plus de robustesse. C’est peu être un processus lent et qui n’est pas sensible au doux souhait des éditeurs, mais ça reste possible.&nbsp; Là ou on nous sort (enfin ressort) l’idée que de changer de techno c’est éventuellement mieux.&nbsp;





Bien évidement, c’est pas comme si on avait rien fait pour la sécurité du C++ ces 20 dernières années. Il y a eu énormément d’amélioration à tous les niveaux : le langage lui même et ses bibliothèques (smart pointers, move semantic, …), en établissant un sous-ensemble restrictif (C++ core guideline) ou via des outils d’analyse statique, d’analyse dynamique, ou des techniques de mitigation de faille (ASRL, NX, …).



&nbsp;Il n’empêche que tous ces efforts sont insuffisants car l’architecture du langage n’a absolument pas été pensée pour la sécurité. Pour rendre le C++ sûr au niveau de la mémoire, il faudrait complètement briser la compatibilité au point d’en faire un autre langage.

&nbsp;



TexMex a écrit :



Il y a un problème dans le monde du logiciel c’est la politique des éditeurs qui, pour imposer leur produits (et donc dominer le marché) doivent séduire les programmeurs. Et plus ces derniers sont fourbis de sièges bébé plus ça leur plaît (plus ils sont crétins aussi). Cela fait baisser le niveau général de maîtrise des programmeurs. Au final ça coûtera moins cher à l’embauche.





&nbsp;Je te conseille de te renseigner sérieusement sur Rust avant de faire des commentaires méprisants. Rust n’est clairement pas le nouveau langage simple d’accès qui fait tout à ta place via un garbage collector comme le Go.

&nbsp;

Rust impose au contraire de comprendre clairement ce que ton programme fait avec sa mémoire, en fait il est même plus exigeant que C++ avec lequel on peut facilement faire un programme qui à l’air de marcher. Le Rust ne gère pas la mémoire à ta place : il te demande de lui démontrer que ce que tu fais avec ta mémoire est correct pour te laisser compiler.







TexMex a écrit :



…on nous dit (enfin suggère subrepticement) qu’un autre langage est mieux.

Oui cette “preuve” est bien fragile en fait. Donc sans montrer de garanties. C’est beau. Parce que bon, on a dit cela de plein de langages.&nbsp;





La preuve est assez claire : de par sa conception ce que l’on appelle les erreurs mémoire à savoir :&nbsp; le buffer overflow, use after free, double free, uninitialized memory, race conditions, … sont impossible en Rust.

Techniquement tout ce qui répond aux undefined behavior en C et C++ n’est pas possible en Rust a moins de passer par un bloc “unsafe”.



&nbsp;



TexMex a écrit :



Il serait plus judicieux d’induire l’idée que l’on pourrait enrichir ces langages (ou les rendre plus flexibles)

avec soit de nouvelles fonctionnalités ou soit des restrictions à la demande via une option de compilation par exemple. Techniquement parlant rien ne l’empêche. Seulement voila beaucoup n’en sont pas capable.

Aussi l’éditeur dans se démarche n’y est pas favorable (dominer le marché, embaucher à peu de frais).





Ce que tu ne comprend pas c’est que ça a été fait et ça continue. Mais le C++ n’ayant pas du tout été fait pour ça,&nbsp; si on veut avoir une vraie garantie de sécurité comme l’apporte le Rust, le langage au final n’aurait au final plus grand chose à voir avec le C++.

Microsoft a essayé diverses approches&nbsp; notamment un “Checked C” et un “C# système” dans le cadre du projet Midori. S’il regardent maintenant plutôt du coté du Rust, ce n’est pas sans raison.

&nbsp;



Super intéressant, merci pour le lien !!








Elioty a écrit :



Je n’ai pas lu tous les commentaires, la discussion est longue mais une nouveauté toute récente concernant l’interopérabilité C++/Rust, les dévs de Firefox ont réussi à faire du LTO (link-time optimization) entre fichiers objet issus de C++ et de Rust !!!

&nbsp;<img data-src=" />

https://www.reddit.com/r/cpp/comments/ch7g6n/mozilla_just_landed_crosslanguage_l…



C’est un peu le niveau ultime de l’interopérabilité quand même… Faut juste que Microsoft se mette à la page <img data-src=" />





Ne t’inquiètes pas, Microsoft est certainement à la page.&nbsp; Mais l’interopérabilité avec le C++, pose de nombreux problème techniques est logiques. Le LTO c’est un problème technique résolu, mais il y en a d’autre



l’ABI notamment n’est pas stable, ni en en Rust, ni en C++. En général pour interfacer C++ et Rust entre eux (et avec d’autre langages) on passe par l’ABI du C qui est stable et utilisable par la majorité des langages, mais aussi plus limitées (pas de template notamment). Pour faire l’interface, il faut généralement passer par une bibliothèque

qui utilise l’ABI C. C’est automatisable, plus ou moins facilement.



Enfin d’un point de vu logique, les éléments de base de C++ et Rust étant différents (templates/generics, surcharge, classes/trait, héritage, …) un appel direct a de test élément, n’est juste pas possible vu qu’il ne répondent pas aux même règles.

&nbsp;



”[…] si plusieurs grosses entreprises se fédère autour deRust pour en faire le langage principal de la prog’ system dans lesannées futures je serais pas contre :).”&nbsp;



&nbsp;Sur le principeOK, mais j’espère que tu laisse quand même Mozilla et la communautépour chapeauter tout ce beau monde. Sans ça je crains que ce langagedevienne sans queue ni tête.









marba a écrit :



Tant que n’importe quelle entreprise ne prenne le lead sur le développement du langage pour tout flinguer, oui ça peut être positif.



<img data-src=" />



Je suis d’accord avec toi, il faut bien trouver un “dénominateur commun” pour brancher deux langages si différents dans leurs grands principes, qui est donc l’ABI du C.



Néanmoins, ce dénominateur commun n’est justement que l’interface binaire des wrappers vers le langage de destination. Sachant que le langage de destination est utilisé pour écrire ce même wrapper, il peut utiliser dans son implémentation les spécificités du langage de destination, mais évidemment pas dans son interface, limitée par l’ABI du C.



Mais une fois le LTO passé, ces wrappers étant généralement courts, ils auront certainement été inlinés donnant un overhead proche de zéro.



Enfin, ça reste du travail pas fait en simplement quelques jours. Pour les types/classes échangés entre les deux langages, il faut faire des wrappers pour tous les services ; pour ce qui est template, il faut faire une “moulinette” qui génère ces wrappers ou les faire à la main comme pour les classes s’il y en a juste quelques-uns, sinon vite chronophage.



Bref, je raconte quasiment la même chose que toi, nous sommes d’accord <img data-src=" />


En effet et c’est bien ce que dit Microsoft : l’interopérabilité est possible mais complexe car elle requiert beaucoup de travail d’adaptation manuel.



Il existe bien “bindgen” : un générateur automatique de code Rust pour le lier à du C ou C++. Il marche plutôt bien mais le code Rust généré a forcément la logique d’origine pas forcément adaptée au Rust (notamment niveau sécurité). Pour une utilisation naturelle en Rust, il faut bâtir par dessus ce code généré des abstractions adaptées ce qui représente beaucoup de travail.








marba a écrit :



En espérant qu’ils fassent de gros dons à Mozilla…





A priori, ils ont offert au projet Rust une infrastructure Azure assez puissante pour faire fonctionner leur intégration continue, ce qui leur a permis de faire des économies substantielles.



Bon et du coup, le compilo rust, il est ecrit en C ou en C++ ?


Python!



Au mpins au premier niveau,je n’ai pas creusé si tout le code du générateur l’était.








uzak a écrit :



Bon et du coup, le compilo rust, il est ecrit en C ou en C++ ?





Il est écrit principalement en Rust, mais il s’appuie sur le backend LLVM qui est en C++. Le python n’est utilisé que pour le script de compilation.



Il est donc quasiment autoporté. C’est bon ça pour ce type de language.








Vincent_H a écrit :



On ne les supprime pas. Ils sont bloqués et les tous leurs comms sont supprimés. Les inscriptions sont faites manuellement, on ne peut pas vraiment lutter contre ça, mais on peut au moins les empêcher d’utiliser le même pseudo (maigre consolation).





Je ne sais pas trop combien de nouveaux commentateurs vous avez chaque jour, mais une solution ne serait elle pas une modération automatique suivi d’une validation manuelle du/des premiers commentaires d’un utilisateur ?



Et si ça fait trop vous pouvez limiter ça aux commentaires contenant des liens.



Pas bête, je vais transmettre :)


Ou limitez définitivement aux abonnés, ça vous fera plus de revenus si les bots à spam sont désespérés à ce point là <img data-src=" />


Je serais quand même curieux de savoir sur le nombre de bugs combien sont dans du code C pur, voire du vieux C++, comparé au nombre de bugs trouvés dans du code plus récent écrit en C++11 mini.

Je ne suis pas très adepte de ranger C et C++ dans le même panier. Écrire du C++ moderne n’a plus grand chose à voir avec du C. Typiquement, des buffer overrun ça fait des années que je n’ai pas eu l’occasion d’en coder, et c’est le genre de bug qui se détecte assez facilement en débug avec les collections de la std.


Indépendamment du langage, en 32 bit, partir du principe de charger en mémoire des fichiers de plus de 1GO est une erreur (et même 512MO dans un environnement managé). En 64bits la limite n’en est pas autant une (ça ne plantera pas), mais ce serait quand même une erreur.


C’est aussi valable quand on travaille avec des bases de données je pense. (je précise, je ne suis pas dev)

J’ai connu un cas d’une application dont les traitements très optimisés (c’est ironique, au cas où) chargeaient la quasi intégralité d’une table de plusieurs millions d’enregs.

Le Tomcat qui portait l’appli derrière (et lui était dédié), il aimait pas trop… Obligé de lui filer à minima 2Go de mémoire pour espérer qu’il n’explose plus.



Même chose pour des traitements en base type PL/SQL et compagnie… Quand on manipule des tonnes de données et qu’on commit pas régulièrement, on se retrouve avec un gaspillage de ressources monumental pour traiter du temporaire.


Je n’avais jamais essayé le Rust, c’est sympa, du coup j’ai aussi essayé le framework web Rocket basé sur Rust, très sympa :-)


+1.

Mais je suppose que c’est tout simplement que TexMex ne connait pas du tout Rust et par conséquent ne se rend pas compte de tout le paradigme qu’il y a derrière pour permettre d’éviter les problèmes de mémoire by design.








TexMex a écrit :



Rien n’empêche de faire évoluer un langage et/ou son compilateur pour plus de robustesse. C’est peu être un processus lent et qui n’est pas sensible au doux souhait des éditeurs, mais ça reste possible.







Comme dit plus haut : si la rétro compatibilité. Quand, dès sa conception, un langage fait le choix de faire fi de la securité pour diverse raison (performance et fonctionnalité principalement, mais il y a aussi la raison que pour certain langage plus ancien, c’était difficile : pas assez de recule et techniquement irréaliste)







TexMex a écrit :



Là ou on nous sort (enfin ressort) l’idée que de changer de techno c’est éventuellement mieux. Avec comme accompagnement son quota de trolls correspondant.







Le gars, il me sort une liste d’argument en quoi c’est mieux qui est cohérent avec mon expérience et il me fait en plus une démo de la façon de régler les problèmes, je ne dis pas non.



Je viens de regarder à quoi ressemble Rust rapidement. Ca semble être très inspiré de C complété d’un système de “policy/trait” pour faire de l’objet. A ceci, ils ont ajouté une contrainte très forte sur la mutabilité des variables. Clairement, Rust est fait avant tout pour la sécurité et la performance. Cependant par la contrainte forte sur la mutabilité des variables, ça risque de le rendre moins pratique que le C++ à l’usage. Cependant, si ton but est de développé une application fiable et performante, effectivement, Rust semble être un très bon choix. Si ton but est seulement la performance et l’indépendance de plateforme, reste sur C ou C++. Si c’est de la pure performance que tu cherches, agrémente ton code d’assembleur (VLC fait un mixte pour certain bout de code : d’abord un code dans un langage plateforme indépendante, et plusieurs mise en œuvre en assembleur spécifique pour les plateformes majoritaires).









TexMex a écrit :



Je suppose que si tu peux citer ces choses de ton dernier paragraphe tu as du rencontrer aussi des “technos révolutionnaires” (las famosas) qui finalement ne font pas vraiment mieux qu’avant. Voire pire.







Dans mes expériences, la première techno qui me vient à l’esprit est la programmation orienté objet. ce paradigme a permis de résoudre des problèmes mais en a créer tout autant si ce n’est pas plus.







TexMex a écrit :



Il y a un problème dans le monde du logiciel c’est la politique des éditeurs qui, pour imposer leur produits (et donc dominer le marché) doivent séduire les programmeurs. Et plus ces derniers sont fourbis de sièges bébé plus ça leur plaît (plus ils sont crétins aussi). Cela fait baisser le niveau général de maîtrise des programmeurs. Au final ça coûtera moins cher à l’embauche.







Et alors ? En quoi est-ce un problème ? Peut-être que tu es touché directement, mais en quoi ça pose problème globalement pour la société ?







TexMex a écrit :



Et on retombe dans le sempiternel “avec ce langage on peut tout faire”. et ensuite je cite : “on ne peut pas faire car la y’a pas de lib pour cela” sorti de la bouche de programmeurs areuh areuh qui ne fera jamais de lib.



L’histoire; bien malheureusement se répète.







Je ne crois pas qu’il y ai un seul langage qui se soit voulu “universelle”. Après, on peut tout faire avec n’importe quel langage qui est turing complet, mais je te mets au défit d’écrire quoi que ce soit d’utile en “brain fuck”.

Chaque langage est situationnel. Personnellement, j’utilise le langage que j’ai besoin dans chaque situation. Aujourd’hui par exemple, j’utilise énormément python pour faire mes scripts ne dépassant rarement les 10000 de lignes.



Ensuite, la théorie des langages est toujours active. Elle permet à la fois de développé de nouveau concept et d’améliorer d’autre concept. L’informatique est un science qui est encore très jeune, et il reste encore énormément de marge d’évolution.



Ce qui fait la force de C et de C++ aujourd’hui, c’est leur héritage. Comme tu le dis, difficile de créer un nouveau projet lorsque tu as tout à rebâtir, là ou C et C++ arrive avec toutes la flopée d’outil, de bibliothèque et de compétence.



Mais connais-tu le dilemme “exploration VS exploitation” ? Soit tu exploites jusqu’à l’os les ressources que tu as soit tu perds du temps a rechercher de nouvelles ressources qui peuvent être bien plus productive. Le problème de l’exploitation, c’est que soit ta ressource va être épuisé, soit qu’un concurrent va te “bouffer” car il aura trouvé un meilleur filon. Dans l’exploration, c’est à chaque fois un lancé de dé, tu peux trouver une mine d’or qui te garantira un rente à vie mais très souvent tu tombera sur un tas de bouse : gros risque mais grosse récompense.



Dans l’innovation, c’est exactement ça : soit tu continue à faire une amélioration continue de ce que tu connais, soit tu prends un risque de tester de nouvelles choses. La bonne réponse est de faire un mixte des 2.



Oui, il faut tester de nouvelles choses, un boite comme MS peut mettre une partie de leur budget dans ce genre de chose (soit investir dans leur propre R&D, soit racheter des petites boites). Ils ont même tout intérêt à le faire pour essayer d’avoir toujours un coup d’avance.



peut etre pas les atomisé il vont recréer un compte, je voterai plus pour un genre de filtre au niveau site



-il voit ses postes comme si de rien n’etait MAIS pas nous :)



un peu comme un compte filtré par mes soins, mais fait par vous meme


Mais pourquoi personne ne parle-t-il d’Ada ? ^^



Memory safe, éprouvé, adapté à la programmation système !


exactement ce à quoi je pensais, c’est de plus en plus utilisé, et ça s’appel le “shadow ban”, ça peux faire perdre pas mal de temps au mecs avant qu’ils ne s’en rendent compte ( mais un contrôle sur les 34 premiers posts d’utilisateur / ceux avec les liens en plus permet de bien diminuer le problème ) ( si ils génère 0 click en provenance du site il vont arrêter/diminuer )



la le problème c’est qu’une partie va ouvrir dans une vm / onglet privé pour regarder quelque genre de scam c’est …


Juste pour apporter mon petit grain de sable, on ne peut pas comparer le C++98 avec le C++ moderne (C++17 et superieur).



Il y a eu un enorme changement d’approche du code ces dernieres années, du code précompilé typé (avec meme des assert statiques et des conditions !), une batterie d’outils de manipulation de variable entierement revue (fini les auto_ptr), la stl plus robuste…



Je serais curieux de voir les stats de de failles de secu liées à un overflow sur un projet de l’ampleur de Windows, mais bati sur du C++ moderne from scratch. M’est avis qu’on serait bien moins alarmiste sur ce beau language…








Aloryen a écrit :



Indépendamment du langage, en 32 bit, partir du principe de charger en mémoire des fichiers de plus de 1GO est une erreur (et même 512MO dans un environnement managé). En 64bits la limite n’en est pas autant une (ça ne plantera pas), mais ce serait quand même une erreur.







Ce n’est une erreur que si ton contexte te permet de faire autrement.

Quand ton objectif est de faire des rapprochements entre le contenu de deux fichiers, que tu ne dispose pas de base de données autres que Access, que tu dois coder en C# un module dans une appli existante et que en plus tu as des contraintes de perf.



Bah… L’objectif est de faire avec pas de le faire avec la meilleur solution “logique”… Bienvenue dans les grandes banques Françaises :)









Toorist a écrit :



tu ne dispose pas de base de données autres que Access,





SQL Server Express n’est pas envisageable?

Vu que dans les grandes banques de mémoire les PCs font souvent office de serveurs, ça doit le faire ;)



au début je pensais naïvement, tiens le lectorat se féminise <img data-src=" />


Ca ne l’était pas…

En gros j’étais dans une équipe commando et et on était rattaché à l’opérationnel et pas à la partie technique de la banque.

Du coup les N+X techniques refusaient de nous octroyer les autorisations pour utiliser des bases de données SQL car réservés aux “pro”.



Bref… bienvenue dans la finance et le management intelligent <img data-src=" />








sephirostoy a écrit :



Je serais quand même curieux de savoir sur le nombre de bugs combien sont dans du code C pur, voire du vieux C++, comparé au nombre de bugs trouvés dans du code plus récent écrit en C++11 mini.

Je ne suis pas très adepte de ranger C et C++ dans le même panier. Écrire du C++ moderne n’a plus grand chose à voir avec du C. Typiquement, des buffer overrun ça fait des années que je n’ai pas eu l’occasion d’en coder, et c’est le genre de bug qui se détecte assez facilement en débug avec les collections de la std.





Le problème c’est que C++11 (et même C++17) n’est pas un nouveau langage qui se distingue clairement de l’ancien. Il se traîne tout l’héritage de C et C++ comme le pointeurs classiques et les références qui restent centraux au fonctionnement du langage.

&nbsp;

Même en utilisant les nouvelles structures il y a de nombeuse façon de mal les utiliser aussi dangereuses que du vieux C++. En fait la complexité rajoutée fait que je ne me sent pas plus sur avec du C++ moderne que du C.

&nbsp;





Vser a écrit :



Mais pourquoi personne ne parle-t-il d’Ada ? ^^



Memory safe, éprouvé, adapté à la programmation système !





Bonne question. C’est vrai que comme langage orienté sécurité, Ada date de bien avant Rust. Après ils n’offrent pas les mêmes garanties. Au niveau de la mémoire, Rust fait mieux tout en laissant plus de contrôle. Après Ada a d’autres avantages par rapport à Rust sur la validation des données notamment.



&nbsp;Je pense que Ada a eu sa chance mais a échoué. Personnellement on m’a forcé à l’apprendre a l’université, et je n’ai pas accroché.

&nbsp;



Les deux comptes ont été bloqués et les comms supprimés. Par contre je suis surpris, tu as bien utilisé la fonction de signalement de commentaire ?