Discussion :

[Bill Fassinou]

Microsoft annonce Rust/WinRT, une projection du langage Rust pour les API Windows Runtime
implémentée comme une bibliothèque basée sur des fichiers d'en-tête

Microsoft a annoncé l’arrivée d’un nouveau membre dans la famille des outils de projection de langage dont fait partie C++/WinRT. C’est Rust/WinRT qui vient de faire son entrée. C’est une projection du langage Rust entièrement standard pour les API Windows Runtime, implémentée comme une bibliothèque basée sur des fichiers d'en-tête, et conçue pour vous fournir un accès de première classe à l'API Windows moderne. Il a désormais une prévisualisation publique sur GitHub. Rust continue de séduire Microsoft.

Windows Runtime (WinRT) est le Runtime de Windows. Il constitue la base des applications de la Plateforme universelle de Windows (UWP). Il se base sur les API COM (Component Object Model) sous le capot et il est conçu pour être accessible par des projections de langage. WinRT peut également être utilisé pour des choses comme les pilotes, ce qui se prête à un code natif très performant. Microsoft soutient principalement ce cas d'utilisation avec C++/WinRT. Mais depuis ce jeudi, Rust a rejoint C++ avec Rust/WinRT. Une bonne nouvelle pour les développeurs Rust.

En effet, ces projections de langage prennent les métadonnées décrivant les différentes API et fournissent des liaisons naturelles pour le langage de programmation cible. Comme vous pouvez l'imaginer, cela permet aux développeurs de créer plus facilement des applications et des composants pour Windows en utilisant le langage de leur choix. Vous pouvez alors utiliser ces API Windows pour créer des applications de bureau, des applications de stockage ou quelque chose de plus unique comme un composant, un service NT ou un pilote de périphérique.

Rust/WinRT suit la tradition établie par C++/WinRT de construire des projections de langage pour le Runtime Windows en utilisant des langages et des compilateurs standards, fournissant une manière naturelle et idiomatique pour les développeurs Rust d'appeler les API Windows. Il permet d'appeler toute API WinRT passée, présente et future en utilisant du code généré à la volée directement à partir des métadonnées décrivant l'API et directement dans votre paquet Rust où vous pouvez les appeler comme s'il s'agissait d'un module Rust parmi d'autres.

« Microsoft a longtemps dépendu du C++ comme épine dorsale pour une grande partie de ses activités, mais elle doit relever certains défis, notamment en matière de sécurité. Le C++ moderne facilite certainement l'écriture d'un C++ sûr et sécurisé si vous suivez certaines conventions prudentes, mais cela est souvent difficile à appliquer sur des projets plus importants. Rust est un langage intrigant. Il ressemble beaucoup au C++ à bien des égards, et il a toutes les qualités requises pour la compilation, le modèle d'exécution, le système de types et la finalisation déterministe », a écrit Microsoft dans un billet de blogue.

« Bien qu'il ait sa propre courbe d'apprentissage unique, il a aussi le potentiel de résoudre certains des problèmes les plus contrariants qui affligent les projets C++. Il est conçu à partir de zéro avec la sécurité de la mémoire et la concurrence sûre comme principes de base », a-t-il ajouté. L'adoption de Rust par Microsoft n’est pas surprenante, car dernièrement, la firme n’a pas cessé de louer les performances du langage développé par Mozilla. L’été dernier, elle a déjà recommandé l’utilisation de Rust comme approche proactive pour un code plus sécurisé.

Selon Microsoft, le C++ a des vertus qui le rendent attrayant et parfois essentiel. Il est très rapide, mature ; avec une exécution prévisible, une faible empreinte mémoire et disque, une plateforme presque inégalée, etc., et vous pouvez l’utiliser sans être obligé d’installer des composants supplémentaires. Ainsi, il estime que si les développeurs pouvaient avoir toutes les garanties de sécurité de la mémoire de langages comme .NET C# combinés à toute l’efficacité du C++, cela leur permettrait de ne pas introduire certains défauts dans leurs logiciels.

« L’un des langages de programmation les plus récents et les plus prometteurs qui répondent à ces exigences est le langage de programmation Rust initialement développé par Mozilla », a expliqué l’équipe Microsoft Security Response Center (MSRC). Toutefois, Microsoft n’est pas la seule entreprise qui plébiscite Rust pour une programmation plus sécurisée. D’autres grands noms de la technologie et de petites entreprises ont commencé à compter sur Rust comme un élément clé dans leur travail. Parmi elles, il y a npm Inc, la société derrière npm, le gestionnaire de paquets de Node.js.

En février 2019, l’entreprise a publié un rapport d’étude avançant que le langage de programmation Rust possède une meilleure façon de gérer les dépendances que d’autres langages tels que Go, C et C++. L’équipe a donc choisi Rust pour faire une nouvelle implémentation d’un service du registre npm pour éviter à la longue les problèmes de performance. Enfin, Microsoft a déclaré que Rust/WinRT est une avant-première publique très précoce, mais que l’équipe a désormais décidé de travailler au grand jour.

Sources : Microsoft, Rust/WinRT

Et vous ?

Qu'en pensez-vous ?

Voir aussi

L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé

L'équipe de npm choisit Rust pour gérer les goulots d'étranglement liés au CPU au détriment de Go, C, C++ et Java. Voici les raisons de ce choix

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

[Astraya]

C'est une excellente nouvelle. En espérant que cela aidera à son adoption dans les entreprises maintenant!

[steel-finger]

C'est vraiment une très bonne nouvelle. Nous avons commencé à utilisé Rust au travail, habituellement on travaille sur C/C++.
Rust est un langage très intéressant, il corrige un certain nombre de défaut qu'on retrouve dans certain langage.

[Mubelotix]

Le temps que je fasse mes études il aura conquéri le monde. J'espère mon expérience déjà avancée en Rust me permettra d'être embauché pour travailler principalement avec ce language génial.

[Uther]

Le temps que tu sois embauché, il est bien possible qu'il soit devenu courant a utiliser, en tout cas il le mériterait certainement.

Mais vu l'omniprésence du C dans l'informatique de bas niveau actuellement, il n'aura certainement pas encore conquis le monde. Il n'y a qu'a voir comment le Cobol que l'on annonce mort depuis 30 ans est encore partout dans certains domaines de l'informatique.

[defZero]

Qu'en pensez-vous ?

MS remonte dans mon estime.
Enfin une autre façon "officiel" de développer sous Windows, sans se coltiner Visual C++ ou autre .Net, bref un changement radicale bienvenue avec tous les avantages qu'apportera Rust.

Le temps que je fasse mes études il aura conquéri le monde.

@Mubelotix

C'est pas méchant, mais ça ma fait rire sur le coups.

J'espère mon expérience déjà avancée en Rust me permettra d'être embauché pour travailler principalement avec ce language génial.

@Mubelotix

Pour ce qui est de travailler avec Rust ça ne dépendra pas vraiment de tes envies / études, mais plus du type de projet sur lesquels tu travaillera.
Si tu t’oriente vers le Web au mieux ce sera du Java / Go / .Net et au pire du PHP / Ruby / Python et dans tous les cas du JS, avec une petite lueur désespoir pour WASM, mais le leagacy restera.

Sachant que le Rust est plutôt un concurrent au C / C++ en entreprise, il te faudra pouvoir travailler sur des projets qui auraient nécessités leur usage, ce qui est loin de correspondre à la majorités des projets actuels et probablement futures, pour des raisons évidentes de productivités et de facilités d'embauches.

Sans compter que pour justifier d'une "expérience avancée", encore faut il la faire valoir en environnement pro.
Ce qui sous entend sois une expérience préalable auprès d'un employeur , sois des projets Open Source d'envergure pour que l'employeur puisse se faire son idée.

Même si je suis d'accord sur le faite que ce soit une nette amélioration par rapport à Visual C++ et .Net, les cas d'usages dans le milieu pro, me semble qu'en même très restreint.

[Uther]

Pour ce qui est de travailler avec Rust ça ne dépendra pas vraiment de tes envies / études, mais plus du type de projet sur lesquels tu travaillera.
Si tu t’oriente vers le Web au mieux ce sera du Java / Go / .Net et au pire du PHP / Ruby / Python et dans tous les cas du JS, avec une petite lueur désespoir pour WASM, mais le leagacy restera.

Je ne doute pas que des langages de plus haut niveau sont dans la plupart des cas plus adaptés pour du Web, mais Rust n'est pas totalement disqualifié dans le domaine non plus. Il peut notamment avoir de l’intérêt dans les parties qui requièrent de la performance, pour gérer des traitement plus lourds que du simple CRUD.

Coté backend, il y a par exemple le framework Actix qui brille par ces performances et le framework Rocket qui fournit une API vraiment propre. Coté frontend, Rust n'est clairement pas le langage le plus adapté, sauf en ce qui concerne le WASM où il est probablement le langage qui offre le meilleur support à l'heure actuelle.

[defZero]

Non pas que je doute que des langages de plus haut niveau soient dans la plupart des cas plus adaptés pour du Web, Rust n'est pas totalement disqualifié dans le domaine.
Il peut notamment avoir de l’intérêt dans les parties qui requièrent de la performance, pour gérer des traitement plus lourds que du simple CRUD.

@Uther

Tout à fait d'accord, mais le vrai problème que va rencontrer Rust à l'avenir est de savoir s'il est assez bon pour justifier la bascule ?

Le type de systèmes nécessitant de la performance pour des traitements lourds que tu décris, aura plutôt tendance à être développé en JAVA, .Net ou Go, pour des raisons de simplicité, de productivité, de main d’œuvre et surtout de coûts.

Est-ce que Rust et son écosystème pourra se justifier dans ces cas là ?

D'autant plus quand on parle d'environnement Web où la notion de performance à un sens somme toute relatif.
C'est principalement pour cela que je mettais le Rust face au C / C++ en environnement Pro et plutôt pour des projets autre que Web.

... Coté backend, il y a par exemple le framework Actix qui brille par ces performances et le framework Rocket qui fournit une API vraiment propre.
Coté frontend, Rust n'est clairement pas le langage le plus adapté, sauf en ce qui concerne le WASM où il est probablement le langage qui offre le meilleur support à l'heure actuelle.

@Uther

Développer un backend sur des frameworks Rust non stable (pré-alpha, alpha), pour des performances dont on n'as pas forcement besoin, c'est prendre de gros risque pour pas grand chose à mon avis et cela que ce soit maintenant ou dans 10 ans (si les projets existent encore).
Pour le front, c'est un peut la même histoire, sachant que de dans tous les cas de figure, un développement JS sera nécessaire, alors pourquoi partir sur Rust pour uniquement une compilation vers WASM alors que d'autres (JAVA, .Net, Go, Typescript ...etc), seront parfaitement apte à remplir l'ensemble des besoins ?

Pour moi le coup de développement en Rust ne peut ce justifié que sur des projets qui auraient été confiés au C / C++, soit des projets relativement lourds, long et couteux de toute façons.

Rust est très capable et je pense a ça place en remplaçant de C / C++ sur certains projets, mais il faut savoir rester pragmatique et ne pas vouloir tout faire avec.
Ne faites pas de Rust le nouveaux NodeJS.
Apprenez à lâchez le marteau et vos problème ne ressemblerons plus tous à des clous .

[Uther]

Le type de systèmes nécessitant de la performance pour des traitements lourds que tu décris, aura plutôt tendance à être développé en JAVA, .Net ou Go, pour des raisons de simplicité, de productivité, de main d’œuvre et surtout de coûts.

Est-ce que Rust et son écosystème pourra se justifier dans ces cas là ?

Je suis conscient que dans la majorité des cas, pour le Web le goulot d'étranglement, c'est plutôt le réseau et la base de données, pas les performances brutes du code. Mais dans les cas ou les performances sont importantes Rust peut tout à fait se justifier. Par exemple Dropbox a rapporté que de passer une partie très consommatrice de son code de Go à Rust leur permis de faire d'énormes économies sur les besoins en matériel. Et puis le framework Rocket offre quand même un cadre de travail bien plus propre que pas mal de frameworks dans des langages de haut niveau.

Je ne dis pas que Rust est forcément le meilleur langage pour le backend, loin de là, juste qu'il n'est pas totalement inintéressant.

Développer un backend sur des frameworks Rust non stable (pré-alpha, alpha), pour des performances dont on n'as pas forcement besoin, c'est prendre de gros risque pour pas grand chose à mon avis et cela que ce soit maintenant ou dans 10 ans (si les projets existent encore).

C'est vrai que Rocket nécessite un compilateur Rust "nightly" car il utilise en interne des fonctionnalités avancées de Rust (qui devraient être définitivement stabilisées cet été), mais l'API du framework lui même est stable. Le framework Actix est stable et fonctionne sans soucis avec les version stables de Rust.
Franchement quand je vois l'état de stabilité de la majorité des frameworks Web les plus utilisés actuellement, je suis plus rassuré par la stabilité des frameworks Rust.

Pour le front, c'est un peut la même histoire, sachant que de dans tous les cas de figure, un développement JS sera nécessaire, alors pourquoi partir sur Rust pour uniquement une compilation vers WASM alors que d'autres (JAVA, .Net, Go, Typescript ...etc), seront parfaitement apte à remplir l'ensemble des besoins ?

Java, .Net et Go sont tout aussi dépendant du JavaScript que Rust. Un des avantages de Rust quand on fait du Wasm, c'est justement qu'il fournit une plutôt bonne intégration avec le JavaScript grâce à wasm-bindgen.

Pour moi le coup de développement en Rust ne peut ce justifié que sur des projets qui auraient été confiés au C / C++, soit des projets relativement lourds, long et couteux de toute façons.
Rust est très capable et je pense a ça place en remplaçant de C / C++ sur certains projets, mais il faut savoir rester pragmatique et ne pas vouloir tout faire avec.
Ne faites pas de Rust le nouveaux NodeJS.
Apprenez à lâchez le marteau et vos problème ne ressemblerons plus tous à des clous .

Je suis entièrement d'accord, c'est bien pour ça que je dis bien qu'il peut avoir son utilité dans certaines situations, pas qu'il est la meilleure solution à tous les problèmes. Ce qui vaut d'ailleurs pour tous les langages.

[Nothus]

C'est une excellente nouvelle

A de nombreux titres àmha.

D'abord parce que si Microsoft "joue le jeu", ce sont des ressources supplémentaires qui peuvent être allouées à l'amélioration et au développement du langage lui-même : du temps d'ingénierie, probablement des propositions et pistes d'amélioration.

Ensuite parce que c'est une étiquette "qualité" (chacun jugera) d'un grand éditeur logiciel pour entreprise (qui ne fait pas que des OS) - et donc favorise l'adoption dans les autres entreprises, si j'en crois un sondage récent sur un usage encore très limité dans le monde professionnel.

Ensuite (bis) parce qu'au-delà de l'étiquette, c'est permettre davantage d'opérations et de processus sur Windows : donc moins de coûts de développement qu'aujourd'hui, plus de potentiel, donc plus facile à porter comme projet dans une organisation. Rust répond par sa sûreté, à des attentes notamment vis-à-vis des normes de l'ANSII et d'une vision plus pro-active de la sécurité.

Ensuite (ter) parce que c'est probablement à terme l'ensemble de l'environnement logiciel de Microsoft qui en aura un usage massif (je pense fort à l'alternative d'Amazon Lambda : Microsoft Function qui aujourd'hui ne supporte encore pas Rust).

Enfin parce que c'est un signal dans le monde du développement. L'effet de mode, au-delà des qualités mêmes de Rust, peut devenir un déclencheur pour des profils développeurs à s'y intéresser, à commencer son relatif mais pénible apprentissage, élargissant l'offre. Émulation dans les entreprises, durant les recrutements IT...

J'ai peut-être et même sûrement la foi du converti récent... mais tant mieux !

[Invité]

Mais dans les cas ou les performances sont importantes Rust peut tout à fait se justifier. Par exemple Dropbox a rapporté que de passer une partie très consommatrice de son code de Go à Rust leur permis de faire d'énormes économies sur les besoins en matériel.

D'après ce que j'ai compris c'est le moteur de synchronisation côté client qui a été réécrit (https://dropbox.tech/infrastructure/...ur-sync-engine) mais pas pour des raisons de performances, plutôt de fiabilité et de testabilité.
Perso, je trouve ce genre de retour d'expérience intéressant mais ça ne prouve pas grand chose. Pour reprendre l'exemple, Dropbox est souvent cité comme exemple de projet réussi en langage Go, maintenant il passe en Rust, et ensuite ? D'ailleurs, il doit également y avoir des projets C qui réussissent très bien et des projets Rust qui échouent lamentablement mais dont personne ne parle.

C'est vrai que Rocket nécessite un compilateur Rust "nightly" car il utilise en interne des fonctionnalités avancées de Rust (qui devraient être définitivement stabilisées cet été), mais l'API du framework lui même est stable. Le framework Actix est stable et fonctionne sans soucis avec les version stables de Rust.

Alors oui, parlons-en des frameworks web en Rust. Je suppose que tu fais référence à ce classement : https://www.techempower.com/benchmarks/. Rocket propose un système d'API typée très intéressant. Mais ce framework n'est pas du tout dans les plus performants.
Actix lui est souvent dans les plus performants, sauf que c'est au détriment de la fiabilité. Ce n'est pas moi qui le dit, mais la communauté Rust elle-même. D'ailleurs, l'auteur du framework a arrêté de contribuer tellement il en avait marre des remarques sur les sections unsafe du code (et au passage, il a même supprimé le dépôt github, avant de se rétracter et de le transférer à d'autres, quelques moments plus tard...).
Donc oui, Rust permet de faire du code fiable et du code performant mais il ne fait pas de miracle non plus.

[Nothus]

D'ailleurs, il doit également y avoir des projets C qui réussissent très bien et des projets Rust qui échouent lamentablement mais dont personne ne parle.

Probable... Il y a cependant même un OS intégralement Rust. J'ai compilé et testé pour voir : ça fonctionne. Bien évidemment tu ne fais rien avec (tu as un bureau, un bloc note, une calculatrice, un lecteur de fichier, un outil de configuration et un terminal). Mais l'exploit est là.

Probablement que le coût en développement ne vaut pas l'effort investi pour la retombée. Mais avoir une complémentarité plus grande C / Rust (avec no_mangle), pour tout ce que fait C aujourd'hui, ça ne me semble pas déconnant. D'autant que tu peux faire une transition de code critique, lib par lib, en tentant de garder la compatibilité.

A tort ? Je suis hors de mes compétences là.

Donc oui, Rust permet de faire du code fiable et du code performant mais il ne fait pas de miracle non plus.

Enfin un écart très léger avec C et la sûreté de la mémoire en plus dans sa définition (et en obligeant "à marquer" le code non-sûr avec unsafe justement) de l'abstraction à coût zéro (facilitant le projet à plusieurs, permettant de réfléchir à une architecture métier et pas seulement logique) et un garbage collector statique...

A la base en plus un projet perso, sur un temps libre durant 3 ans...

Perso je tire mon chapeau !

[Invité]

Probable... Il y a cependant même un OS intégralement Rust. J'ai compilé et testé pour voir : ça fonctionne. Bien évidemment tu ne fais rien avec (tu as un bureau, un bloc note, une calculatrice, un lecteur de fichier, un outil de configuration et un terminal). Mais l'exploit est là.

En quoi est-ce un exploit ? Je peux me tromper mais je crois que les OS existaient avant Rust... Il y a en même en Lisp : https://github.com/froggey/Mezzano

Enfin un écart très léger avec C et la sûreté de la mémoire en plus dans sa définition (et en obligeant "à marquer" le code non-sûr avec unsafe justement)

Mais non, justement : la sureté mémoire à un coût. Rust a l'avantage de permettre une gestion sûre par défaut et de faire explicitement du unsafe, si nécessaire, mais on n'a pas magiquement une gestion sûre ET les performances du C. D'ailleurs, si tu regardes les codes de ton benchmark, tu trouveras beaucoup de unsafe (https://benchmarksgame-team.pages.de...dy-rust-7.html), et donc on perd des garanties de gestion mémoire sûre.

de l'abstraction à coût zéro (facilitant le projet à plusieurs, permettant de réfléchir à une architecture métier et pas seulement logique) et un garbage collector statique...

Je ne voudrais pas être méchant mais je ne suis pas sûr que tu comprennes vraiment ce que tu racontes. Pour en revenir à Rust, le langage a beaucoup d'avantages mais ce n'est pas une raison pour le survendre (ni pour rester aveugle à d'autres langages qui ont aussi des avantages).

[Nothus]

En quoi est-ce un exploit ? Je peux me tromper mais je crois que les OS existaient avant Rust... Il y a en même en Lisp : https://github.com/froggey/Mezzano

C'était pour illustrer que ce que tu fais en C, tu peux le faire en Rust, avec peut-être certaines garanties supplémentaires.

si nécessaire, mais on n'a pas magiquement une gestion sûre ET les performances du C. D'ailleurs, si tu regardes les codes de ton benchmark, tu trouveras beaucoup de unsafe

Va au bout de la logique : le code de la bibliothèque standard de Rust est composé de blocs "unsafe" un peu partout. Ce que je voulais dire, maladroitement sûrement, c'est que lorsque tu sors d'un contexte sûr en Rust qui est le "normal", tu dois le notifier explicitement et le rendre sûr pour l'utiliser de façon normale ailleurs.

Tu gères l'équilibre, en faisant le compromis entre sûreté ou non. Mais tu le fais explicitement et pas à crédit dans un projet...

...facilitant le projet à plusieurs, permettant de réfléchir à une architecture métier et pas seulement logique

Tu définis quelque chose quelque part, en passant par des structures et autres énumérations. Si tu veux que le compilateur fasse le job, tu ne peux pas avoir une variable par exemple non-initialisée qui serait de ce type quelque part, ailleurs. Tout changement quelque part se doit d'être suivi plus précisément.

C'était ça l'intérêt du travail facilité en groupe. Architecture de "concepts métier"... la réponse à des besoins et son intégration dans une organisation plus vaste.

Je ne voudrais pas être méchant mais je ne suis pas sûr que tu comprennes vraiment ce que tu racontes.

Non tu as certainement raison. Me voilà rhabiller pour le reste de l'année : excuse-moi de t'avoir déranger. Bonne fin de weekend !

[epsilon68]

il faut voir comment rust evolue, car c++ a 30 ans d'evolution derriere lui, en relevant les nouveaux defis qui se presentaient.

il y a plein de projets fait en C ou c++ qui sont geniaux : sqlite, git, webkit
pourquoi eux y arrivent mais pas les autres ?

Quand je vois en entreprise le niveau du code rien qu'en C#, j'ai vraiment peur. Je crois que fondamentalement, les problèmes ne sont pas dans le langage ... je n'imagine meme pas ce que ca pourrait donner en C++, je n'ai plus confiance, la majorité doit coder avec le "luc"... En quoi Rust serait une solution ? les problèmes sont beaucoup plus basique que ca, l'algo est faux, ou over compliqué, le code est dupliqué 50 milliard de fois, le ownership d'une ressource n'est pas compris (qui detient mon context ?), les structures de données ne sont pas maitrisées.

et puis aussi, pour 95% des programmeurs, on est dans l'informatique de gestion, alors comment faire mes UI en rust ? comment je me connecte à ma db ? ne veut on pas plutot un truc qui marche a coup sur ? C# ou java, faire des ui simplement ? genre WPF...

je crois que rust au final est reservé à un tout petit pourcentage de codeurs, et en fait je continue de penser que les problemes sont ailleurs.

Comme par exemple quelqu'un qui a recodé une appli en swift... pour ensuite s'apercevoir d'un temps de compilation plus long, des complication dans la gestion des non-nullable etc, il a ensuite recodé en objective c avec une bien meilleure architecture... bref comme disait joel on software, tu peux perdre un temps infini de ré-ecrire ton soft en changeant la techno (a peu pres tous les 10 ans) ou bien tu peux rester competitif et implementer les fonctionalités qui manquent, en plus de refactorer.

Je pense qu'il y a moins de risque a encapsuler en C++ un programme existant vieux de 20 ans, que de tout re-ecrire en rust. En C++, on sait ou on va, mais en rust ?

[Invité]

Tu définis quelque chose quelque part, en passant par des structures et autres énumérations. Si tu veux que le compilateur fasse le job, tu ne peux pas avoir une variable par exemple non-initialisée qui serait de ce type quelque part, ailleurs. Tout changement quelque part se doit d'être suivi plus précisément.

C'était ça l'intérêt du travail facilité en groupe. Architecture de "concepts métier"... la réponse à des besoins et son intégration dans une organisation plus vaste.

Merci pour cette précision. Ca ne correspond pas tout à fait à ce que je comprends du zero-cost abstraction, d'où mon incompréhension.

Non tu as certainement raison. Me voilà rhabiller pour le reste de l'année

C'est juste que le "garbage collector" statique et le zero-cost abstraction pour la gestion de projet à plusieurs, ça n'a pas vraiment de sens pour moi. Mais effectivement ma remarque était formulée de façon stupide, excuse-moi.

[Uther]

Perso, je trouve ce genre de retour d'expérience intéressant mais ça ne prouve pas grand chose. Pour reprendre l'exemple, Dropbox est souvent cité comme exemple de projet réussi en langage Go, maintenant il passe en Rust, et ensuite ? D'ailleurs, il doit également y avoir des projets C qui réussissent très bien et des projets Rust qui échouent lamentablement mais dont personne ne parle.

Encore une fois, il ne s'agit pas de prouver la supériorité définitive d'un langage sur un autre. Il s’agissait de relativiser une déclaration un peu trop absolue sur l’intérêt de Rust dans certains domaines. Je dis juste que Rust peut avoir de l'intérêts dans certains cas où on ne l'imagine pas forcément au premier abord, même si je ne doute pas que dans beaucoup d'autres cas, d'autres langages peuvent avoir encore plus d’intérêt.

Alors oui, parlons-en des frameworks web en Rust. Je suppose que tu fais référence à ce classement : https://www.techempower.com/benchmarks/. Rocket propose un système d'API typée très intéressant. Mais ce framework n'est pas du tout dans les plus performants.
Actix lui est souvent dans les plus performants, sauf que c'est au détriment de la fiabilité. Ce n'est pas moi qui le dit, mais la communauté Rust elle-même.

Je suis bien au courant de ça, et c'est bien pour ça que j'ai pris la peine de prendre deux cas différents et que j'ai pris la peine de distinguer les forces de chacun d'entre eux. Encore une fois celui qui cherche l'outil parfait qui résoudra parfaitement tous les problèmes informatiques n'a pas fini de chercher. Il n’empêche que les deux solutions sont potentiellement intéressantes en fonction de ce que l'on recherche.

Donc oui, Rust permet de faire du code fiable et du code performant mais il ne fait pas de miracle non plus.

Autant pour moi, c'est vrai que j'ai vraiment fait beaucoup d'effort pour présenter Rust comme une solution miracle :

Non pas que je doute que des langages de plus haut niveau soient dans la plupart des cas plus adaptés pour du Web, Rust n'est pas totalement disqualifié.

Coté frontend, Rust n'est clairement pas le langage le plus adapté

C'est bien pour ça que je dis bien qu'il peut avoir son utilité dans certaines situations, pas qu'il est la meilleure solution à tous les problèmes.

[epsilon68]

comme Linus Torvalds a dit

What do you think of the projects currently underway to develop OS kernels in languages like Rust (touted for having built-in safeties that C does not)?

That's not a new phenomenon at all. We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters.

I'm not convinced about Rust for an OS kernel (there's a lot more to system programming than the kernel, though), but at the same time there is no question that C has a lot of limitations.

To anyone who wants to build their own kernel from scratch, I can just wish them luck. It's a huge project, and I don't think you actually solve any of the really hard kernel problems with your choice of programming language. The big problems tend to be about hardware support (all those drivers, all the odd details about different platforms, all the subtleties in memory management and resource accounting), and anybody who thinks that the choice of language simplifies those things a lot is likely to be very disappointed.

[Uther]

En quoi est-ce un exploit ? Je peux me tromper mais je crois que les OS existaient avant Rust... Il y a en même en Lisp : https://github.com/froggey/Mezzano

C'est clairement pas un exploit, juste une démonstration plutôt probante que Rust est utilisable de manière idiomatique en tant que langage système.
Je sais qu'on à vu des trucs louches comme des OS en Java, mais en général c'était du gros bricolage. Je ne connaissait pas Mezzano, ça a l'air intéressant, je regarderai si j'ai le temps, mais si c'est vraiment totalement en LISP, je suppose que ça doit aussi impliquer des trucs discutables du genre d'avoir un interpréteur en ring 0.

Mais non, justement : la sureté mémoire à un coût. Rust a l'avantage de permettre une gestion sûre par défaut et de faire explicitement du unsafe, si nécessaire, mais on n'a pas magiquement une gestion sûre ET les performances du C. D'ailleurs, si tu regardes les codes de ton benchmark, tu trouveras beaucoup de unsafe (https://benchmarksgame-team.pages.de...dy-rust-7.html), et donc on perd des garanties de gestion mémoire sûre.

Même si en Rust on doit parfois renoncer à la sécurité pour les performances, le fait qu'on ne le fasse que partiellement, et au cas par cas, reste un gros avantage.
Pour reprendre ton exemple, en un coup d’œil on voit que la plupart des blocs "unsafe" sont des instruction SIMD qui ne touchent pas du tout à la mémoire et qui sont donc parfaitement safe (tout le SIMD est considéré unsafe même si toute les instructions le sont pas réellement). Les seules instruction SIMD de ce programme potentiellement dangereuses pour la sécurité mémoire sont _mm_loadh_pd, _mm_loadl_pd et _mm_store_pd qui manipulent des pointeurs unsafe.

Donc pour vérifier que tout le programme est sûr niveau mémoire, il suffit de vérifier que ces 3 instructions ne font pas de dépassement, ce qui est relativement simple. Avec un code équivalent en C il m'aurait fallu analyser l'intégralité du programme, je n'aurais pas été capable de te faire un diagnostic aussi rapide avec autant d'assurance.

il faut voir comment rust evolue, car c++ a 30 ans d’évolution derrière lui, en relevant les nouveaux defis qui se presentaient.

il y a plein de projets fait en C ou c++ qui sont geniaux : sqlite, git, webkit
pourquoi eux y arrivent mais pas les autres ?

On a construit des cathédrales sans camions, ni marteau-piqueur, ça ne veux pas dire que ces outils sont inutiles maintenant que l'on en dispose.
D'ailleurs sqlite, git, webkit, ... n'ont pas miraculeusement évité les problème de vulnérabilité mémoire. C'est pas pour rien que Mozilla a été le premier sponsor de Rust. Les erreur de mémoires sont la principales source de vulnérabilité grave que l'on trouve dans les navigateurs qu'ils soient basés sur Webkit, Trident ou Gecko.

les problèmes sont beaucoup plus basique que ca, l'algo est faux, ou over compliqué, le code est dupliqué 50 milliard de fois, le ownership d'une ressource n'est pas compris (qui detient mon context ?), les structures de données ne sont pas maitrisées.
Quand je vois en entreprise le niveau du code rien qu'en C#, j'ai vraiment peur. Je crois que fondamentalement, les problèmes ne sont pas dans le langage ... je n'imagine même pas ce que ca pourrait donner en C++, je n'ai plus confiance, la majorité doit coder avec le "luc"... En quoi Rust serait une solution ?

Pour un algo éronné, en effet Rust ne te sera d'aucun secours, par contre si le ownership n'est pas maîtrise, justement Rust ne te laissera pas compiler ton code. Un gros intérêt de Rust est qu'il permet d’empêcher complètement cette catégorie d'erreurs pas facile à appréhender.

Une erreur d'algo, ça se trouve en général relativement vite avec des bons test. Une erreur de mémoire on peut facilement la faire sans s'en rendre compte, et même les projets sérieux avec gens expérimentés ne sont pas à l’abri.

Les gardes fous apportés par Rust sont d'autant plus important quand est persuadé que l'on travaille avec des nuls, mais il ne faut pas oublier que même les meilleurs sont des nuls parfois.

Comme par exemple quelqu'un qui a recodé une appli en swift... pour ensuite s'apercevoir d'un temps de compilation plus long, des complication dans la gestion des non-nullable etc, il a ensuite recodé en objective c avec une bien meilleure architecture... bref comme disait joel on software, tu peux perdre un temps infini de ré-ecrire ton soft en changeant la techno (a peu pres tous les 10 ans) ou bien tu peux rester competitif et implementer les fonctionalités qui manquent, en plus de refactorer.
Je pense qu'il y a moins de risque a encapsuler en C++ un programme existant vieux de 20 ans, que de tout re-ecrire en rust. En C++, on sait ou on va, mais en rust ?

C'est fou que dès que l'on parle de Rust, les développeurs C++ s'imaginent qu'on leur demande de réécrire l'intégralité du code existant en Rust. Ça n'est bien évidement pas près d'arriver. On ne récrit pas un code dans un nouveau langage sans une bonne raison de faire ça.
Par contre, le Rust sait au moins autant où il va que le C++, qui a énormément plus évolué, particulièrement ces dix dernières années.

[Invité]

C'est fou que dès que l'on parle de Rust, les développeurs C++ s'imaginent que l'on va les obliger à réécrire l'intégralité du code existant en Rust.

oui, c'est fou, on se demande d'où vient cette idée
https://www.reddit.com/r/rust/commen...ts_to_convert/