Rust/WinRT, une projection du langage Rust pour les API Windows Runtime

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.

Pièce jointe 561952

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 ?

:fleche: Qu'en pensez-vous ?

Voir aussi

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

:fleche: 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

:fleche: Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D

:fleche: C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust

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

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.

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.

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.

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.

Citation:

---

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.

Citation:

---

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 :aie:, 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.

Citation:

---

Envoyé par defZero

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.

Citation:

---

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.

Citation:

---

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

Citation:

---

Envoyé par defZero

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.

Citation:

---

Envoyé par defZero

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.

Citation:

---

Envoyé par defZero

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.

Citation:

---

Envoyé par defZero

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.

C'est une excellente nouvelle :D

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 ! :heart:

Citation:

---

Envoyé par Uther

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.

Citation:

---

Envoyé par Uther

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.

Citation:

---

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

Citation:

---

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 !

Citation:

---

Envoyé par Nothus

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

Citation:

---

Envoyé par Nothus

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.

Citation:

---

Envoyé par Nothus

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

Citation:

---

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.

Citation:

---

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

Citation:

---

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

Citation:

---

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 !

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 ?

Citation:

---

Envoyé par Nothus

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.

Citation:

---

Envoyé par Nothus

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.

Citation:

---

Envoyé par SimonDecoline

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.

Citation:

---

Envoyé par SimonDecoline

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.

Citation:

---

Envoyé par SimonDecoline

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 :

Citation:

---

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

---

Citation:

---

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

---

Citation:

---

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.

---

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.

Citation:

---

Envoyé par SimonDecoline

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.

Citation:

---

Envoyé par SimonDecoline

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.

Citation:

---

Envoyé par epsilon68

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.

Citation:

---

Envoyé par epsilon68

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.

Citation:

---

Envoyé par epsilon68

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.

Citation:

---

Envoyé par Uther

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/

Oui enfin la c'était visiblement surtout quelque quidams lambda sur Github qui venaient sans doute de découvrir Rust peu après sa sortie, et qui ne connaissent visiblement pas grand chose, les utilisateurs de Rust sont généralement les premiers a s'en moquer.
Y'a pas de vraie demande de fond à tout réécrire en Rust.

Hello :)

Je profite de ce topic pour partager mon point de vue et recueillir le vôtre. Pour info je suis spécialisé C++ et n'ai qu'une connaissance légère de Rust. Mais je m'intéresse pas mal à comment ce langage évolue et comment il est adopté dans l'industrie car de manière générale je suis passionné par comment les langages interagissent entre eux.

En lisant certains messages, je crois qu'il est important de préciser que ce qui fait le succès d'un langage ce n'est pas (simplement) ses qualité intrinsèques. C'est peut être même un aspect secondaire. Son écosystème et le support (financier) qu'il reçoit sont des facteurs essentiels : bibliothèques disponibles, IDE / debug / profiling, intégration avec d'autres systèmes, portabilité, etc... Donc surtout ne pas réduire un langage à sa syntaxe quand on veut comparer les utilisations (penser à comment javascript s'est imposé comme langage n°1!). Et donc le fait qu'il reçoive du soutient de la part de Microsoft est une très bonne chose pour le langage.

Un autre point à rappeler est que Rust n'est pas le premier langage à s'attaquer à C/C++ en apportant des innovations qui sont, objectivement, intéressantes. J'ai personnellement lu moultes démonstrations expliquant pourquoi ADA, Objective C, Eiffel, D, Nim... sont de meilleurs langages que C++. Mais il y a un petit détail : C++ est un langage avec un spectre d'utilisation extrêmement large dans plusieurs secteurs aux contraintes très différentes. Le remplacer sur certains segments est une tâche accessible, remplacer le langage de manière large est une tout autre histoire. Et il me semble que Rust occupe aujourd'hui la position de challenger que d'autres ont occupé avant lui (le langage D en particulier, qu'il a à mon avis tué) et peine à en sortir. Non pas qu'il n'en sortira jamais, mais il peine.

Et à mon avis c'est lié au segment sur lequel on le positionne presque systématiquement : la sécurité. Et c'est pas vraiment le plus porteur. Pour rappel les discussions sur la sécurité ne sont pas nouvelles : PASCAL se vantait d'être beaucoup plus secure que le C, et puis au final nos composants système les plus critiques (OS, drivers...) sont écrits en C... tandis que PASCAL n'est plus... De plus - et c'est pas un détail - il existe des solutions logicielles pour fiabiliser des programmes en C et C++. Le hic est qu'elles sont souvent payantes, à vil prix. Mais pour les structures qui ont ces besoin c'est acceptable. Et pour les domaines où ça ne suffit pas, genre l'aérospatiale, les personnes concernées avec qui j'ai pu en discuter ne juraient en général que par ADA, ou alors des solutions style Frama-C.

Donc pour moi Rust a un peu le cul entre deux chaises : pour les environnements critiques genre aérospatiale, il est face à plus qualifié que lui. Et pour les autres cas d'usage, et bien il a quand même un gros côté overkill. En particulier face à un langage comme Go et son approche "get the shit done". En effet y a quand même beaucoup de boites qui arrivent à correctement développer des logiciels en C ou C++ sans vraiment être troublées par des problèmes de sécurité : leurs problèmes au quotidien sont ailleurs. Oui certains bugs constatés ne se seraient pas produits avec Rust, mais ce n'est pas ce qui gêne le plus en pratique car l'outillage hyper mature aide à rattraper beaucoup de choses. Ca me parait important de le souligner car je trouve qu'au niveau communication sur Rust il y a une trop forte focalisation sur cet aspect dont au final peu de monde accord une forte importance. Je donne un exemple réel : dans une conf un mec répond à une question sur pourquoi il faudrait choisir Rust en expliquant pendant plusieurs minutes commet Rust offre de super garanties de sécurité en termes de programmation multi-thread etc... Puis il demande s'il a répondu à la question => "heu... nous on n'utilise pas de threads alors je sais pas". A trop se focaliser sur un aspect parmi tant d'autres, ça peut vite se retourner contre le langage en réduisant la perception de son champ d'application réel.

Enfin, pour qui essaye de suivre l'intégration de Rust dans Firefox, Mozilla n'envoie pas des signaux très positifs. Pour moi là ils ont clairement merdé quand leur comm. Ca a pris beaucoup plus de temps qu'annoncé, l'effet "silver bullet" tant vanté n'a pas vraiment eu lieu, et aujourd'hui le navigateur est en sérieuse difficulté face à ses concurrents intégralement propulsés en C++ : pas de quoi rassurer un décideur. C'est difficile d'avoir les raisons précises de ces difficultés, mais de ce que j'ai pu trouver comme information (j'ai du chercher sur les blogs perso de certains développeurs...) ça confirme ce que j'ai dit au début : développer une brique logicielle dans un coin est une chose. Intégrer cette brique dans des systèmes existants est une autre paire de manches. Et dans un environnement où à peu près tout repose sur C et C++, et bien ces 2 langages ont un avantage. La news ci-dessus vient rappeler cette dépendance en tout un tas de couches de compatibilité / intégration, et c'est avec ce genre de "détails" (qui se multiplient sur les gros projets) que commencent à se diluer tous les avantages qu'on a pu gagner ailleurs.

Par exemple j'ai lu le témoignage de développeurs qui au début ont été enthousiastes avec Rust, et puis ont fini par jeter l'éponge face à ses lacunes dans le domaine de la 3D en particulier. L’écosystème C++ dans ce domaine est colossal, et un nouveau langage ne peut pas rivaliser avec de multiples bibliothèques qui ont souvent +20 ans de développement ininterrompu dans des domaines très pointus. Sans parler, semble-t-il, de la prise de tête que c'est de coder des structures de données complexes telles des arbres ou des graphes.

Face à C, je suis aussi assez dubitatif - mais pour d'autres raisons. D'abord parce que C++, malgré sa possibilité de l'utiliser comme un meilleur C, n'est pas parvenu à convaincre les développeurs récalcitrants. Ceux que j'ai pu fréquenter travaillaient tous dans le domaine embarqué, et avaient comme point commun d'être très à l'aise avec des concepts bas niveau de hardware et d'électronique, de masquage de bits, etc... et par contre de très vite décrocher quand on commence à parler d'abstraction, POO, patterns, etc... Je ne suis même pas arrivé à les convaincre de l'utilité d'une classe vector ou string par rapport à une gestion manuelle ou via des macros. C'est une autre façon de penser le code, et c'est pourquoi je vois mal n'importe quel langage les convaincre. Y'a que Go semble-t-il, qui en séduit quelques uns (Ken Thompson doit y être pour quelque chose).

Donc au final désolé si je casse un peu l'ambiance, mais j'essaye de faire la part des choses entre ce qu'on aimerait qu'il se passe, et ce qu'il peut réellement se produire. Faire basculer des équipes de développement vers un nouveau langage ne répond pas aux mêmes critères de décision que choisir un langage pour un projet perso from scratch sur github. C'est un peu comme comparer 20 ans de vie de couple avec un flirt d'été :D Par le passé y'a eu des vagues d'enthousiasme et d'intérêt pour des langages comme D, F#, Haskell. Ces langages ont innové et ont clairement apporté quelque chose à tous ceux qui les ont étudiés à en devenir super fan. Avec aussi, il faut le dire je crois, ce petit côté "ça c'est un vrai langage pour les vrais programmeurs" qui en pratique se marie assez mal avec le pragmatisme de l'industrie.

Personnellement je suis très content que Rust soit là et contribue à faire progresser notre métier. Mais j'ai l'impression qu'on se dirige plus vers un marché de niche qu'une adoption massive du langage. Et les quelques retours d'expérience qui commencent à circuler tendent à confirmer cela.

Je pense en effet que c'est honorer une techno que d'en reconnaitre les limites, pour éviter de la mettre dans des situations où elle n'est pas adaptée et peut causer des dégats / déceptions. Paradoxalement, plus on connait les faiblesses et lacunes d'un langage, plus il devient fiable car sa zone de risque se clarifie. Et je trouve que c'est quelque chose qui manque encore beaucoup au sujet de Rust : des retours contrastés sur son emploi. Beaucoup de discours sont dithyrambiques, on a l'impression de lire des plaquettes commerciales : pas vraiment de quoi rassurer sur la maturité du langage. Donc si vous avez des retours d'expérience plus nuancés sur la base d'une utilisation sérieuse je suis preneur !

Ceci étant dit, j'aimerais conclure ce message un peu "douche froide" par ce qui est pour moi l'essentiel : le fait d'aimer un langage est une raison suffisante pour pratiquer ce langage. J'ai mis plusieurs années à comprendre que l'affinité qu'on peut avoir avec un langage n'est pas quelque chose de rationnel, mais relève plutôt du goût et des couleurs. Partant de là, y'a pas à rationaliser pourquoi on préfère ce langage. Car chaque langage capture une certaine façon de penser les choses, et quand on est se découvre en phase avec l'une d'elle alors y'a juste à se laisser porter afin de d'explorer tout ce qu'il y a à découvrir avec cette façon de faire. On en retire forcément quelque chose. Et à y réfléchir, c'est quand même plus sympa de choisir un langage sur un coup de coeur !

J'attends vos réactions en espérant avoir blessé personne :)

Citation:

---

Envoyé par Aurelien.Regat-Barrel

J'attends vos réactions en espérant avoir blessé personne :)

---

Bien au contraire, la vocation d'un langage n'est pas d'être utilisé par tout le monde pour tout les usage. Il n'y a pas de raison de se sentir blessé par une critique constructive d'un langage : on parle d'un outil pas d'une personne de sa famille.

Votre analyse est très pertinente. Je vais forcément répondre aux points ou j'ai des choses a redire, mais je tiens à préciser que je la partage globalement.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

le langage D en particulier, qu'il a à mon avis tué

---

Je ne suis pas sur que Rust ait vraiment tué D. Malgré sa plus longue histoire, D n'a jamais réussi à percer. La niche qu'il visait en priorité, celle du langage compilé relativement performant mais qui fait quelque concessions pour la simplicité (notamment le GC), a surtout été prise par le Go.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Et à mon avis c'est lié au segment sur lequel on le positionne presque systématiquement : la sécurité. Et c'est pas vraiment le plus porteur. Pour rappel les discussions sur la sécurité ne sont pas nouvelles : PASCAL se vantait d'être beaucoup plus secure que le C, et puis au final nos composants système les plus critiques (OS, drivers...) sont écrits en C... tandis que PASCAL n'est plus... De plus - et c'est pas un détail - il existe des solutions logicielles pour fiabiliser des programmes en C et C++. Le hic est qu'elles sont souvent payantes, à vil prix. Mais pour les structures qui ont ces besoin c'est acceptable. Et pour les domaines où ça ne suffit pas, genre l'aérospatiale, les personnes concernées avec qui j'ai pu en discuter ne juraient en général que par ADA, ou alors des solutions style Frama-C.

---

Je suis assez d'accord que le positionnement sur la sécurité dans la communication autour de Rust à ses limites. Ça a l'avantage de le présenter sous son coté le plus singulier, le système d'ownership intégré au langage étant sans vrai équivalent dans les autres langages. Mais il est vrai que c'est aussi un problème car ce n'est pas la préoccupation principale de la majorité des développeurs.

Il semble d'ailleurs que les créateurs de Rust essaient de plus en plus à mettre en valeur les avantages de Rust au delà de la sécurité. Réduire Rust à la sécurité, c'est réducteur (désolé du pléonasme). Il a beaucoup d'autres avantages par rapport a certains de ces concurrents dans la programmation système, même s'ils sont moins singuliers. On a par exemple une très bonne gestion des dépendances, le pattern matching, ...
Du plus, en dehors de la gestion de la sécurité mémoire, il est globalement bien plus simple que le C++ (modularité, constructeurs, héritage,...)

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Donc pour moi Rust a un peu le cul entre deux chaises : pour les environnements critiques genre aérospatiale, il est face à plus qualifié que lui.

---

Ada a des avantages indéniables par rapport à Rust a niveau de la sécurisation en général notamment au niveau de la validation des paramètres bien qu'il ne couvre pas non plus tout ce qui est couvert par Rust au niveau de la sécurité mémoire.
Misra-C, à surtout l'avantage d'être un standard bien défini, mais au final c'est juste des règles d'utilisation du C, pas un langage en soi. Ça revient d'ailleurs en bonne partie à demander au programmeur d'éviter lui même des choses que Rust empêche complètement de par sa nature. Un Misra-Rust serait aussi utile.

Après ça ne me choque pas de voir que Rust n'est pas encore adopté dans ces domaines, ils ne travaillent pas aux mêmes échelles de temps que le reste de l'informatique. Le gros problème de Rust pour les environnements critiques, c'est surtout qu'il est jeune et continue d'évoluer dans un domaine par essence très conservateur. Il y a un effort en cours qui vise a produire une version de Rust plus stable et mieux spécifiée dédiée aux environnements critiques, mais tout ça prend du temps.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Enfin, pour qui essaye de suivre l'intégration de Rust dans Firefox, Mozilla n'envoie pas des signaux très positifs. Pour moi là ils ont clairement merdé quand leur comm. Ca a pris beaucoup plus de temps qu'annoncé, l'effet "silver bullet" tant vanté n'a pas vraiment eu lieu, et aujourd'hui le navigateur est en sérieuse difficulté face à ses concurrents intégralement propulsés en C++ : pas de quoi rassurer un décideur.

---

Sur le cas de Firefox je n'ai pas du tout la même vision, vous pourriez être plus précis sur ce qui vous donne cette impression. Mozilla n'a jamais annoncé qu'il allait remplacer totalement C++, encore moins promis de délai. Ils ont juste intégrés des briques en Rust en remplacement de certaines partie du moteur. L’intégration de Rust dans Gecko s'est quand me relativement bien passée et donne plutôt satisfaction, même si l'introduction d'un nouveau langage donne forcément du travail.
Quant à la difficulté de Firefox en terme de part de marché, c'est difficile de la rattacher à Rust. C'est surtout du a l'omniprésence de Chrome. Firefox était en difficultés en terme de part de marché, comme tous les concurrents de Chrome, bien avant le choix d'intégrer du code en Rust. C'est le dernier gros moteur web fonctionnel qui n'est pas dérivé de Webkit. Même Microsoft a jeté l'éponge avec son moteur qui était pourtant lui aussi en pur C++.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Hello :)

Je profite de ce topic pour partager mon point de vue et recueillir le vôtre...

---

Salut, Merci pour ce retour. Je suis assez d'accord avec tes analyses.

Pour moi, un autre point qui joue contre Rust, c'est sa communauté apparente. Avant de me faire lyncher, je précise que c'est mon ressenti personnel et que c'est souvent le cas dès qu'un langage apparait, ce n'est pas spécifique à Rust. Je code très peu en Rust mais je connais quelques personnes qui en font régulièrement. Certains l'utilisent comme un outil et c'est généralement très intéressant de discuter avec eux. Mais il y a aussi pas mal de fanboys qui vendent du rêve pas toujours justifié.

Juste comme ça, je veux bien croire que Rust a probablement le meilleur support de wasm mais il faudrait m'expliquer en quoi il est meilleur que Emscripten. De même, pourquoi un OS en Rust c'est une démonstration probante alors qu'un OS en Lisp c'est a priori louche ? Quant à la gestion mémoire forcément correcte en Rust alors que C++ ne garantit rien, il faudrait quand même rappeler que ça vient au prix d'un effort d'apprentissage, que ça ne corrige pas magiquement les sections unsafe, et surtout il faudrait préciser de quel C++ on parle car il y a une différence entre le C++85 et le C++20. Et aussi arrêter de croire que dès qu'on pose une question sur Rust, on est forcément un vieux dev C++ qui a peur d'avoir à évoluer.

Citation:

---

Envoyé par SimonDecoline

Juste comme ça, je veux bien croire que Rust a probablement le meilleur support de wasm mais il faudrait m'expliquer en quoi il est meilleur que Emscripten.

---

Tout d’abord, c'est très simple d'accès car intégré directement à la suite de compilation. Le backend wasm est installable, soit avec emscripten (et sa couche de compatibilité avec la libc) ou sans (plus léger) en une ligne de commande, aussi facilement que celui pour x86,x86_64, ou arm.
Ensuite il y a l'outil wasm-bindgen qui permet au code Rust d'interagir de manière très simple et naturelle avec le code JavaScript et les API Web.
Enfin c'est pas lié au langage lui même mais Rust une assez grosse communauté qui travaille sur des projets WASM.

Citation:

---

Envoyé par SimonDecoline

De même, pourquoi un OS en Rust c'est une démonstration probante alors qu'un OS en Lisp c'est a priori louche ?

---

A part le fait d'être écris en Rust, Redox n'a rien de particulier a signaler par rapport a un OS classique écris dans un langage de bas niveau. Le compilateur Rust fait plus de vérification que le C avant de générer le code, mais les exécutables produits sont similaires.

Un OS en Lisp me parait plus louche parce que, même si je suis pas un expert du langage, il me semble qu'il a besoin d'un interpréteur pour fonctionner. Si l'OS est totalement écrit en Lisp, y compris le kernel, ça voudrait dire que l'interpréteur est au cœur de l'OS, en ring 0, ce qui est atypique et a probablement des impacts lourds.
En tant qu’exploit technique, c'est très intéressant, mais je doute qu'on puisse arriver à quelque chose de performant et fiable en restant sur cette base. Je suis très curieux de savoir comment ils gèrent le matériel en LISP, qui à ma connaissance n'est pas adapté pour ça.

Pour info, il existe un projet d'OS, qui vise à fonctionner intégralement avec une VM WebAssembly en Ring 0. Il a beau être écris en Rust, ce projet me parait encore plus louche qu'un OS en Lisp, bien que là aussi j'apprécie l'originalité de la démarche.

Citation:

---

Envoyé par SimonDecoline

Quant à la gestion mémoire forcément correcte en Rust alors que C++ ne garantit rien, il faudrait quand même rappeler que ça vient au prix d'un effort d'apprentissage, que ça ne corrige pas magiquement les sections unsafe, et surtout il faudrait préciser de quel C++ on parle car il y a une différence entre le C++85 et le C++20.

---

L'effort d'apprentissage supplémentaire du Rust est réel par rapport a des langages comme Go ou Java, où le Garbage Collector résout la plupart des soucis sans avoir a se poser de question.
Mais en comparaison à C++ il est a relativiser. Apprendre a faire du C++ moderne de manière sécurisée, nécessitera le même d'effort d'apprentissage.

Citation:

---

Envoyé par SimonDecoline

Et aussi arrêter de croire que dès qu'on pose une question sur Rust, on est forcément un vieux dev C++ qui a peur d'avoir à évoluer.

---

Vu que je me sens un peu visé, bien que j'ai essayé d'être on ne peu plus clair là dessus : Je ne considère pas les développeurs C++ comme des vieux aigris. Je suis juste surpris que certaines remarques à propos du Rust laissent sous-entendre une peur du "grand remplacement".
L'intérêt de Rust en fonction des situations doit bien sur être discuté (comme toute technologie), et le C++ n'est pas près de disparaître.

Citation:

---

Envoyé par Uther

Un OS en Lisp me parait plus louche parce que, même si je suis pas un expert du langage, il me semble qu'il a besoin d'un interpréteur pour fonctionner. Si l'OS est totalement écrit en Lisp, y compris le kernel, ça voudrait dire que l'interpréteur est au cœur de l'OS en ring 0, ce qui est atypique et a probablement des impacts lourds...

---

Je ne suis pas un expert lisp non plus mais SBCL est capable de compiler du code et a des performances plutôt correctes (entre 1.1 et 6.8 fois C++ si on en croit le classique benchmark qui ne prouve rien mais que tout le monde cite https://benchmarksgame-team.pages.de.../sbcl-gpp.html). Après je suis d'accord que c'est juste un proto et que ça ne va pas concurrencer linux, c'était juste pour nuancer la remarque comme quoi faire un OS avec autre chose que du C serait un exploit.

Pour le reste, merci pour les infos, je suis assez d'accord avec toi, en fait.

Mon gros problème avec Rust, c'est que je trouve sa syntaxe dégueulasse.

J'ai essayé d'apprendre le langage, mais je trouve la syntaxe à gerber.

Il y a une grosse part d'habitude dans le ressenti de la syntaxe d'un langage. Au début avec l'habitude du Java / C++, le langage Rust me paraissait bizarre sur certains points. Maintenant, c'est vraiment le C++ que je trouve mal fichu par rapport au Rust.