Discussion :

[CaptainDangeax]

Moi, je veux bien apprendre un nouveau langage qui est plus simple, plus rapide et plus sécurisé. Mais pour ça il faut que:
- il y ait des compilateurs disponibles pour les cibles que j'utilise (ce n'est pas le cas)
- si le compilateur est disponible, il faut qu'il y ait les librairies disponibles (je n'ai pas encore cherché, je termine les projets en cours d'abord)
C'est aussi simple que ça

[NotABread]

Je trouve que certains oublient bien vite que le choix d'un langage de programmation est un choix technique. Il se base sur:
- le budget
- le temps
- les ressources disponible
- les besoins

Par exemples, j'ai écris un bot pour Discord:
- budget: 0€, je ne veux utiliser que ce que j'ai actuellement
- temps: une dizaine d'heure
- ressources disponible: moi, une lib pour faciliter l'usage de l'api discord, mon pc et mes petits doigts musclés
- besoins:
- tourner h24
- consommer le moins de RAM et de CPU possible
- résister aux saisis malicieuse

J'ai éliminé dès le début JS, je n'ai pas les connaissances pour m'assurer qu'il n'y a pas d'injection de code, un oubli pourrait vite compromettre mon serveur. Python aurait donner des résultats très rapidement et certainement suffisant pour mon usage mais pour tourner des jours sans interruption, il me faudra des try/catch sur tout ce qui peut échouer, et pour la beauté de l'art, je voulais quelque chose de plus optimisé en CPU et RAM.
Au final, j'ai choisi Rust car il répondait à tous mes critères et je voulais tester le langage, j'aurais aussi pu le faire en Golang. Je ne regrette pas ce choix pour ce projet perso, des mois que le bot tourne et a résisté au tentative d'injection et autre, la seule interruption que j'ai eu fut en raison d'une coupure d'électricité. Les points noirs que j'ai vu, c'est un exécutable de 200 Mo et l'usage de la RAM qui tourne autour de 100 Mo. Je pense que les moulte dépendances en sont principalement responsable, mais au moins, l'usage de la RAM reste stable.


L'ajout de Rust dans Linux semble plus que pertinent de part la garantie de la sécurité mémoire et les performances très proche de C. Il sera dommage de s'en priver parce que "c'est pas du C, moi je suis un vrai développeur qui peut faire du C mieux que tout le monde donc j'en ai pas besoin"

[Fagus]

Python aurait donner des résultats très rapidement et certainement suffisant pour mon usage mais pour tourner des jours sans interruption, il me faudra des try/catch sur tout ce qui peut échouer, et pour la beauté de l'art, je voulais quelque chose de plus optimisé en CPU et RAM.

Python est lent en général (quoique pour la plupart des usages c'est good enough), mais sur les exceptions, il ne faut pas hésiter à en mettre, c'est tellement optimisé que c'est gratuit tant que l'exception n'est pas déclenchée.

[Uther]

Moi, je veux bien apprendre un nouveau langage qui est plus simple, plus rapide et plus sécurisé. Mais pour ça il faut que:
- il y ait des compilateurs disponibles pour les cibles que j'utilise (ce n'est pas le cas)
- si le compilateur est disponible, il faut qu'il y ait les librairies disponibles (je n'ai pas encore cherché, je termine les projets en cours d'abord)
C'est aussi simple que ça

Si vous cherchez un langage plus simple, Rust n'est pas forcément le meilleur choix. Il est techniquement plus simple que le C++, mais bon ça c'est pas très difficile. Par contre, il ne fait clairement pas partie des langages taillé sur mesure pour la simplicité comme Go, ou Python. Il y a clairement des notion particulières a appréhender.
Pour le compilateur, en effet ça va dépendre de vos cibles. En général ce qui est supporté par LLVM est supporté par Rust, mais tout n'a pas un support optimal.
Pour les bibliothèques, il commence a y avoir pas mal de choix, et sinon il y a toujours moyen de s'interfacer avec un bibliothèque C.

[OuftiBoy]

Bonjour à tous,

« Les développeurs Linux sont des mégalomanes pédants et condescendants », d’après le créateur de redox_os
Remonté contre les habitués du C qui freinent les mises à jour de la base de code du noyau vers Rust

Sur ce point, je ne saurais donner d'opinions (la mégalomanie), car je n'ai jamais fréquenté cette communauté.
Mais que je peux comprendre, c'est le pourquoi les mainteneurs actuels freinent les mise à jour de la base du code du noyau vers Rust (ou au autre langage) meilleur que le C. (Il n'y a pas de meilleurs langage, il y a seulement des langages mieux adapté pour résoudre un problème que d'autres).

Après plus de 30 ans, un deuxième langage a fait l’objet d’adoption pour le développement du noyau Linux : Le Rust. Linus Torvalds vient de faire un bref état des lieux en termes d’adoption après une année : le taux d’adoption de Rust comme langage de programmation pour le noyau Linux reste faible. Le créateur de Linux a exprimé sa déception à propos de cette situation dont la raison profonde est en train de faire surface : Les principaux mainteneurs du noyau sont plus habitués au langage C et veulent poursuivre sur cette lancée. Ils refusent donc de porter le code existant en Rust ou de passer du temps pour aider d’autres contributeurs à le porter en Rust.

Si de nouveaux mainteneurs veulent introduire (ce qui n'est pas interdit) le Rust c'est à eux qu'ils revient la charge d'une bonne introduction.

Quand je lis: Les principaux mainteneurs du noyau sont plus habitués au langage C et veulent poursuivre sur cette lancée. Ils refusent donc de porter le code existant en Rust ou de passer du temps pour aider d’autres contributeurs à le porter en Rust. Je suis tout à fait d'accord avec eux.

• Si les nouveaux veulent introduire Rust, c'est à eux de faire la démarche de comprendre la base C existante.
  
  Les mainteneurs historique ne veulent pas aider d'autres contributeurs à le porter en Rust. Ils sont là pour coder ces vieux développeurs barbus, ils ne sont pas des instituteurs ou des formateurs pour expliquer à d'autres comme faire un portage vers un autre langage qu'une nouvelle génération veut utiliser.
  
  C'est cette génération qui doit faire le pas. S'il veulent ajouter Rust sans vouloir comprendre ou connaître le C, je ne vois pas comment ils pourraient le faire correctement. En gros, ils demandent aux autres de faire se travail pour eux.

C’est le débat sur la comparaison entre les langages de programmation C et Rust qui prend un coup de neuf

Les rapports en lien avec cette situation font en effet état de ce qu’un sous-ensemble de contributeurs au noyau en langage C sont déterminés à rendre la vie dure aux mainteneurs Rust. Motif : Ils considèrent que Rust n’apporte pas de plus-value significative et préfèrent donc que ce langage de programmation soit mis de côté dans le cadre du développement du kernel.

On parle ici des développeurs extrêment expérimentés du noyaux. S'il considèrent que Rust n'apportent pas de plus-value significativent au [kernel] on peut quand même prendre leur opinion au sérieux, me semble-t-il ?

Quand au fait qu'il semblerait qu’un sous-ensemble de contributeurs au noyau en langage C sont déterminés à rendre la vie dure aux mainteneurs Rust, de quoi parlent ils ? Il y a de bonnes raisons expliquant cela dans la suite du message.

Pièce jointe 658926

Linus Torvalds lui-même est pourtant d’avis que le langage Rust est une solution d’avenir pour le développement du noyau. Il considère la prise en charge de Rust pour le développement du noyau Linux comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

Soit, je le conçois parfaitemment, mais ce n'est pas le sujet. Ce n'est pas parce que d'autres on fait le pas, qu'il faut que le noyau linux le fasse.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

Voilà une partie très intéressante. Je reprend les chiffres donnés: 2288 en 20 ans. 2288/20 = 144,4. 15,9% de ces vulnérabilités à des problèmes lié au C (gestion mémoire, dépassement de tampons, allocation non libérées, accà des zones mémoire invalide ou libérée, etc)

15,9% de 144,4, c'est en arrondissant [B]30[/], soit 1,5 vulnéralité par an. Comparée à l'immense base de code du noyau linux, c'est particulièrement faible. Et ça n'implique certainement de changer le langage utilisé pour ce noyau.

De plus, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

Bien, certains benchmarks, disent que Rust. Mais de combien de % sont-elles plus "rapide" ? Pas de grand chose, et d'autres benchmarks disent le contraire.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.

Une partie de ces "atouts" sont annihilés par le fait qu'il faut passer en mode "unsafe" pour certains accès au noyau. Et donc une partie de l'avantage de Rust s'évapore à cause de ce passage en mode "unsafe" qu'il est forcé d'utiliser à certains endroits.

Pièce jointe 658927

Les habitués du langage C n’entendent pas se laisser embarquer dans ce qu’ils appellent la nouvelle religion du Rust
Les mainteneurs du noyau réfractaires à la mise à jour des bases de code du noyau Linux vers le langage Rust ont fait savoir quelle est leur position lors d’une présentation des systèmes de fichiers Linux et des besoins en termes de migration des bases de code vers le Rust. Il était question pour ces derniers de créer des passerelles permettant de faciliter l’atteinte de cet objectif. L'un des membres de l'auditoire a exprimé son désaccord en disant : « Vous essayez de convaincre tout le monde de passer à la religion du Rust, mais cela n’arrivera pas. »

Je peux les comprendre... Quand il faut créer des "passerelles", ça ajoute une couche de complexité. Puisque ces "passerelles" sont apparement nécessaires pour l'introduction du code Rust dans le noyau, c'est à eux que revient cette chargent, et pour se faire, ils doivent être aussi compétant en C qu'en Rust.

Ces derniers multiplient donc des attitudes qui frustrent certains mainteneurs Rust qui choisissent de quitter le navire : « Ce type de traitement est exactement la raison pour laquelle j'ai entamé le projet @redox_os en partant de zéro et en l'écrivant principalement en Rust. Il y a beaucoup de résistance aux changements bénéfiques, même mineurs, dans Linux et les projets connexes. C’est la raison pour laquelle je n'essaie même plus de contribuer au noyau Linux. Il y a des projets pour lesquels vous devrez inévitablement faire passer vos changements devant des mégalomanes pédants et condescendants, et si le noyau Linux n'est pas seulement développé par ce type de personnalité, il est aussi contrôlé par lui de manière écrasante. »

• J'ai entamé le projet @redox_os en partant de zéro et en l'écrivant principalement en Rust. Je ne connais pas ce projet @redox_os, mais s'il a fallut 30 ans pour que Linux soit ce qu'il est aujourd'hui, je doute fort que @redox_os le fasse en quelques années seulement. Principalement en Rust. Faul-t-ol comprendre que pour certaines parties, Rust ne fait pas le taf ?
  
  Quand au fait de parler de faire passer vos changements devant des mégalomanes pédants et condescendants (je redis que je ne connaît pas cette communauté), et que de cela découle le fait de créer un nouveau noyaux (ou OS complet, je ne sais pas), montre en tout cas très peu d'humilité, mais également un sentiment de supériorité face à des gens qui ont fait leurs preuves depuis 30 ans.
  
  Ce que l'auteur de @redox_os prend pour de la condécendance venant de mégalomanes pédants, est peut être le résultat d'une frustration fassent à des gens plus compétant que lui. Je ne sais, je ne juge pas. Ils "freinent" peut-être l'arrivée de Rust, car cela pourrait se produire à nouveau avec d'autres langages, ou parce qu'ils préférent parler de ce qu'ils connaissent le mieux.

Pièce jointe 658928

Certains des mainteneurs pointent des raisons additionnelles comme l’instabilité de l’infrastructure Rust comme raison de poursuivre avec le C

Greg Kroah-Hartman, le mainteneur du noyau stable, a dit qu’il n’était pas opposé à l’idée d’une branche Rust, mais qu’il faudrait qu’elle soit maintenue par quelqu’un d’autre que lui. Il a aussi demandé comment le code Rust serait testé, et s’il y aurait des outils pour vérifier la qualité du code et la conformité aux normes de codage du noyau. Ojeda a répondu qu’il y avait déjà des outils pour le formatage du code Rust, et qu’il travaillait sur un outil pour vérifier les règles spécifiques au noyau. Il a aussi dit qu’il y avait des tests unitaires pour le code Rust, et qu’il espérait que le code Rust serait intégré dans les systèmes de test existants du noyau.

• ...et qu’il travaillait sur un outil pour vérifier les règles spécifiques au noyau. Et bien qu'il continue son travail sur cet outils, qui, d'après lui même n'est pas terminé. Puis il pourra avancer.
  
  il espérait que le code Rust serait intégré dans les systèmes de test existants du noyau. C'est évident, mais cette charge de travail revient à ceux qui veulent introduire Rust, et donc à la communauté Rust

Dave Chinner s'inquiète du fait que les responsables manquent d'expertise pour examiner correctement les abstractions en cours de fusion. Airlie a répondu que les responsables fusionnent désormais de nombreuses API C sans vraiment comprendre comment elles fonctionnent. De nombreuses erreurs ont été commises au cours du processus, mais « nous sommes toujours là ». Lorsque des choses s’avèrent être cassées, elles peuvent être réparées, et cela se produira plus rapidement si le code remonte en amont.

• Dave Chinner dit: ils manquent d'expertise pour examiner correctement les abstractions en cours de fusion.
  
  Airlie dit: les responsables fusionnent désormais de nombreuses API C sans vraiment comprendre comment elles fonctionnent. Youpie, ça va ne faire que du bien...

Ted Ts'o s'est dit préoccupé par le fardeau que l'ajout du code Rust imposerait aux responsables. Les développeurs de Rust établissent des normes plus élevées que celles fixées par le passé, a-t-il déclaré. Fusionner de bonnes abstractions est une chose, mais qui est responsable de la révision des pilotes et comment les modifications à l'échelle de l'arborescence seront-elles gérées ? L’effort de Rust, a-t-il dit, arrive à un point où il touche une partie croissante de la communauté.

Fusionner de bonnes abstractions est une chose, mais qui est responsable de la révision des pilotes et comment les modifications à l'échelle de l'arborescence seront-elles gérées ?

Bonne question, je n'ai pas la réponse, mais je comprend que les anciens développeur C ne veulent être de la partie...

Williams a souligné que durant la session précédente, la difficulté de faire migrer les sous-systèmes du noyau vers de nouvelles API avait été évoquée ; maintenant, dit-il, on parle de passer à un tout nouveau langage. Hellwig a déclaré que le vrai problème est que les liaisons Rust ont tendance à fonctionner différemment des API C pour lesquelles elles fournissent des abstractions ; les nouvelles API sont peut-être meilleures, mais ce sont toujours des API complètement nouvelles. Ce qu’il faudrait faire, dit-il, c’est d’abord corriger les API C afin qu’elles soient directement utilisables par le code Rust. Il a proposé que, pour chaque sous-système envisageant d'introduire du code Rust, un an ou deux soient d'abord consacrés au nettoyage de ses API dans ce sens. Ojeda a déclaré que ce type d'amélioration de l'API s'était déjà produit dans certains sous-systèmes.

• le vrai problème est que les liaisons Rust ont tendance à fonctionner différemment des API C.
  
  Les nouvelles API sont peut-être meilleures, mais ce sont toujours des API complètement nouvelles.
  
  C’est d’abord corriger les API C afin qu’elles soient directement utilisables par le code Rust. [B]certes, et c'est aux développeurs Rust que cette chargent doit revenir, encore une fois. Et encore une fois, cela implique qu'ils soient aussi d'excellent développeur C
  

Linus Torvalds a déclaré qu'il voyait un fossé entre le système de fichiers et les responsables des pilotes. Les développeurs du côté des systèmes de fichiers ont tendance à être plus conservateurs, tandis que le monde des pilotes « c'est le Far West ». Les auteurs de pilotes ont tendance à ne pas comprendre la concurrence, a-t-il déclaré, et une grande partie du code est défectueux et irréparable. Il n’est donc pas surprenant qu’il y ait un intérêt à introduire un langage qui prenne mieux en charge l’écriture d’un code correct et sûr.

Si Linus le dit, c'est que cela doit être vrai: Une grande partie du code est défectueux et irréparable. Un code est toujours réparable, et il ne doit être réécrit que s'il pose problème. L'histoire a prouvé que réécrire une même fonctionnalité, soulevait les mêmes problèmes, et que la "nouvelle" version n'est pratiquement jamais 100% compatible avec l'ancienne version.

Le domaine banquaire a tenté plusieurs fois de remplacer le vieux code COBOL et que cela n'a jamais aboutit, parce que la nouvelle version n'était pas 100% compatible (offrir les même service de même manière).

Brauner a déclaré que Rust peut aider à résoudre de nombreux problèmes, car le compilateur peut empêcher de nombreux bogues de pénétrer dans le noyau. Mais il s'inquiétait de savoir s'il y aurait un support pour le mainteneur et le développement dans quelques années. Airlie a de nouveau mentionné les développeurs avec du code hors arborescence nécessaire au code Rust; Cook a répondu que les personnes qui supervisent ce code sont des responsables, et que l'introduire entraînerait les responsables avec lui. Airlie a ajouté que ces responsables sont le genre de jeunes développeurs que la communauté du noyau aimerait attirer.

Ts'o a demandé quand la communauté se sentirait suffisamment en confiance pour pouvoir avoir des modules dont la seule implémentation est dans Rust. Binder pourrait être un bon début, a-t-il déclaré, peut-être suivi par un pilote dont l'utilisation serait plus large. Airlie a déclaré qu'il envisageait un pilote graphique virtuel qui réimplémenterait un pilote C existant. Il existe également le pilote pour les GPU Apple M1. Il ressent une forte pression pour l'amener en amont et se demande s'il y a une raison pour laquelle il devrait le garder à l'écart. Après cela, il adorerait voir une réécriture du pilote Nouveau pour les GPU NVIDIA.

Arnd Bergmann a déclaré que ces pilotes pourraient être OK, mais qu'il faudra un peu plus de temps avant que quelque chose comme un pilote de clavier puisse être fusionné ; La chaîne d'outils n'est tout simplement pas prête, a-t-il déclaré, pour un pilote qui serait largement utilisé. Cela a conduit à une question sur les mises à niveau fréquentes de version observées dans le noyau, qui est passé à Rust 1.73.0 pour 6.7. Ce processus de mise à niveau finira par s'arrêter et une version minimale de Rust sera définie une fois que les fonctionnalités importantes dont dépend le noyau se seront stabilisées. Il a déclaré qu'il travaillait pour intégrer le code du noyau dans les tests d'intégration continue de Rust afin de garantir qu'il continue de fonctionner à mesure que le compilateur et le langage évoluent.

La chaîne d'outils n'est tout simplement pas prête, a-t-il déclaré, pour un pilote qui serait largement utilisé. Cela a conduit à une question sur les mises à niveau fréquentes de version observées dans le noyau, qui est passé à Rust 1.73.0 pour 6.7.
il s'inquiétait de savoir s'il y aurait un support pour le mainteneur et le développement dans quelques années...

Ce processus de mise à niveau finira par s'arrêter et une version minimale de Rust sera définie une fois que les fonctionnalités importantes dont dépend le noyau se seront stabilisées.

Cest du bon sens. Le noyau linux ne peut pas être construit sur un langage qui évolue toujours en permanance. Rust n'est pas "prêt" actuellement, laissons-le se stabiliser avant de l'intégrer dans un si grand projet.

Bergmann a déclaré qu'il n'avait pas l'intention d'examiner sérieusement le langage jusqu'à ce qu'il puisse être compilé avec GCC. Torvalds a répondu que, même s'il avait l'habitude de trouver des problèmes dans le compilateur LLVM Clang, il est désormais plus susceptible de rencontrer des problèmes avec GCC ; il construit maintenant avec Clang. Ojeda a déclaré qu'il travaillait à la recherche de ressources de développement pour gccrs ; le projet repose actuellement sur plus de 800 correctifs hors arborescence et a encore beaucoup de travail à faire en plus. Le soutien du CCG prendra du temps, a-t-il déclaré.

Ojeda a déclaré qu'il travaillait à la recherche de ressources de développement pour gccrs ; le projet repose actuellement sur plus de 800 correctifs hors arborescence et a encore beaucoup de travail à faire en plus...

Il n'y a peut-être pas autant de développeurs compétant que de développeurs C compétant. Rust est encore jeune.

Ts'o s'est plaint du fait que le langage n'est toujours pas entièrement stable. Cela pourrait constituer un problème particulier pour la communauté informatique confidentielle ; ils sont préoccupés par la sécurité et, par conséquent, par les rétroportages vers des noyaux supportant à long terme. Mais si ces noyaux sont sur des versions Rust différentes, ces rétroportages seront problématiques. Ojeda a déclaré que, bien qu'il s'agisse d'une "idée folle", le rétroportage des mises à niveau de version pourrait être envisagé. Il ne pense cependant pas que le taux de changement sera suffisamment élevé pour constituer un problème.

• le langage (Rust) n'est toujours pas entièrement stable. Je peux comprendre la réticence des anciens développeurs C.
  
  Ils (les développeurs de Rust)sont préoccupés par la sécurité et, par conséquent, par les rétroportages vers des noyaux supportant à long terme. Mais si ces noyaux sont sur des versions Rust différentes, ces rétroportages seront problématiques.

Je ne peux qu'être d'accord, on batit sur du dur, pas sur du sable...

En conclusion, Torvalds a souligné qu'il y avait eu des problèmes au fil des années avec les changements de GCC qui cassaient le noyau ; la même chose arrivera sûrement avec Rust, mais ce sera finalement la même chose. La séance, bien au fil du temps, a été interrompue à ce stade. Reste à savoir si la communauté du noyau a réellement conclu à son engagement envers Rust ; il y aura presque certainement des Pull Request ajoutant du code Rust important dans un avenir proche.

Torvalds a souligné qu'il y avait eu des problèmes au fil des années avec les changements de GCC qui cassaient le noyau ; la même chose arrivera sûrement avec Rust, mais ce sera finalement la même chose.

Peut-être, mais dans ce domaine, c'est plutot un status-quo qu'un avantage pour Rust.

Et vous ?

Je pense qu'il est urgent d'attendre...

Quels sont les avantages et les inconvénients de Rust par rapport au C pour le code du noyau ?
Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

[fdecode]

Si vous cherchez un langage plus simple, Rust n'est pas forcément le meilleur choix. Il est techniquement plus simple que le C++, mais bon ça c'est pas très difficile. Par contre, il ne fait clairement pas partie des langages taillé sur mesure pour la simplicité comme Go, ou Python. Il y a clairement des notion particulières a appréhender.
Pour le compilateur, en effet ça va dépendre de vos cibles. En général ce qui est supporté par LLVM est supporté par Rust, mais tout n'a pas un support optimal.
Pour les bibliothèques, il commence a y avoir pas mal de choix, et sinon il y a toujours moyen de s'interfacer avec un bibliothèque C.

Déjà, on ne peut pas faire l'impasse d'une compréhension de la gestion des données en mémoire (la pile et le tas).
C'est un préalable à la compréhension de la sémantique de prêt qui est incontournable dès le début pour écrire du code compilable en Rust.
Un petit détail comme le fait que la donnée soit copiable (et stockée dans la pile) ou non copiable a des conséquences sur l'accès aux données.
Par exemple:

• Le code: [playground]

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

   let a = [[1,2],[3,4]]; let x = a[0]; let y = a[1];

  compile car les sous-tableaux '[1,2]' et '[3,4]' sont copiables
• Alors que le code: [playground]

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

   let a = [vec![1,2],vec![3,4]]; let x = a[0]; let y = a[1];

  ne compile pas car les sous-tableaux 'vec![1,2]' et 'vec![3,4]' sont non copiables (stockés dans le tas). Il s'ensuit que les affectations sur 'x' et 'y' nécessitent un move non autorisé des données.

Rien de bien compliqué, mais c'est le genre d'exemple déroutant pour le débutant en Rust. Et au début, avant d'avoir des réflexes de conduite, on en rencontre souvent des petits exemples comme ça...

[fdecode]

C'est cette génération qui doit faire le pas. S'il veulent ajouter Rust sans vouloir comprendre ou connaître le C, je ne vois pas comment ils pourraient le faire correctement. En gros, ils demandent aux autres de faire se travail pour eux.

À ce niveau, cela m'étonnerait que les contributeurs Rust ne connaissent pas le C.
Et en réalité, la connaissance du C facilite grandement la compréhension de Rust (de mon point de vue).

[floyer]

.
Voilà une partie très intéressante. Je reprend les chiffres donnés: 2288 en 20 ans. 2288/20 = 144,4. 15,9% de ces vulnérabilités à des problèmes lié au C (gestion mémoire, dépassement de tampons, allocation non libérées, accà des zones mémoire invalide ou libérée, etc)

15,9% de 144,4, c'est en arrondissant [B]30[/], soit 1,5 vulnéralité par an. Comparée à l'immense base de code du noyau linux, c'est particulièrement faible. Et ça n'implique certainement de changer le langage utilisé pour ce noyau.

… pourquoi diviser 2288 par 20 deux fois… une fois pour passer à 144,4… puis une deuxième fois de 30 (qui représente déjà un nombre annualisé) à 1,5.

Une partie de ces "atouts" sont annihilés par le fait qu'il faut passer en mode "unsafe" pour certains accès au noyau. Et donc une partie de l'avantage de Rust s'évapore à cause de ce passage en mode "unsafe" qu'il est forcé d'utiliser à certains endroits.

Qu’une partie, et ça peut suffire pour éviter certains bugs: certaines protections de Rust restent en mode unsafe. Compile avec ou sans unsafe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
     let s1 = String::from("hello");
    let s2 = s1;
    println!("{s1}, world!");

Tu auras la même erreur liée aux emprunts (borrowing).

Idem pour les indices de tableau.

Et de manière plus générale, devoir placer des unsafe là où l’on s’écarte de certaines règles usuelles permet de situer là où il faut faire plus attention. L’idée est d’éviter de déclarer toutes les fonctions unsafe.

Principalement en Rust. Faul-t-ol comprendre que pour certaines parties, Rust ne fait pas le taf ?

Il est probablement difficile de faire de la commutation de processus sans assembleur (manipulation du registre CR3 x86). Idem pour plusieurs autres aspects d’un OS.

[Metal3d]

Je vais même pas faire un long commentaire, je trouve juste ultra ironique qu'une personne de la communauté Rust trouve d'autres développeurs "condescendants"

[OuftiBoy]

… pourquoi diviser 2288 par 20 deux fois… une fois pour passer à 144,4… puis une deuxième fois de 30 (qui représente déjà un nombre annualisé) à 1,5.

Oui, ce n'est pas clair, et j'ai commis une erreur. Désolé.

Je refait le calcul
Je divise par 2288/20 pour avoir le nombre de vulnérabilité produit chaque année, soit 144,4 vulnérabilités par année.

Ensuite, je prend 15,9% de ces 144,4 car c'est le nombre de bugs "attribué" à une mauvaise utilisation de C (fuite mémoire, utilisation d'un pointeur déréférencé, etc). Et 15,9% de 144,5 ça donne environ 23 bugs par an dû à une mauvaise utilisation du C.

Puis 23/12 (il y'a douze mois dans une année) = 1,999... soit 2 bugs par moins.

Qu’une partie, et ça peut suffire pour éviter certains bugs: certaines protections de Rust restent en mode unsafe. Compile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
     let s1 = String::from("hello");
    let s2 = s1;
    println!("{s1}, world!");

Tu auras la même erreur liée aux emprunts (borrowing).

Idem pour les indices de tableau.

Je ne dis pas le contraire, ni que Rust ne peut pas apporter des solutions à certains problèmes.

Et de manière plus générale, devoir placer des unsafe là où l’on s’écarte de certaines règles usuelles permet de situer là où il faut faire plus attention. L’idée est d’éviter de déclarer toutes les fonctions unsafe.

Je ne dis pas le contraire, et je comprend l'idée derrière "unsafe". En théorie, on ne devrait l'utiliser qu'en dernier recours, mais l'homme est ainsi fait, et rien ne pourra empêcher d'utiliser 'unsafe" plus que ce qu'il nécessaire. Un développeur Rust peut aussi se tromper (comme tout le monde), et employer "unsafe" là où ce n'est pas nécessaire.

Il est probablement difficile de faire de la commutation de processus sans assembleur (manipulation du registre CR3 x86). Idem pour plusieurs autres aspects d’un OS.

Oui, il faut aussi des partie en assembleur à ce bas niveau, et le passage à Rust n'y changera rien. J'ai écrit un petit RTOS, et je confirme qu'on ne peut pas se passer de l'assembleur.

Avoir zéro bugs, c'est presqu'impossible, mais ça peut se corriger. Pour les problèmes de mauvaise implémentation d'un Algo, C ou Rust, c'est kif-kif.

En tout cas, la balance entre Rester en C ou Passer à Rust reste largement favorable à Rester en C. Le passage à Rust a un "coût" qui n'est pas actuellement justifié.

Voilà, mais ce n'est que mon opinion et je ne prétend pas avoir la science infuse.

BàT et Peace & Love.

[Uther]

Si de nouveaux mainteneurs veulent introduire (ce qui n'est pas interdit) le Rust c'est à eux qu'ils revient la charge d'une bonne introduction.

Et c'est exactement le cas. L'introduction de Rust a été faite de manière prudente en limitant Rust a des modules isolés. Les gens qui travaillent sur Rust4Linux ne demandent pas aux contributeurs qui ne sont pas intéressés par les modules en Rust de lire, ni d'écrire la moindre ligne de Rust.
A priori, la seule chose qui leur a été demandée c'est, dans certains cas, d'expliciter les règles que doivent actuellement respecter l'API des drivers, bref des choses qui sont de toute façon nécessaire pour faire des drivers C corrects et qui auraient dues être officiellement documentées. Le système de type de Rust permettra d'assurer que ces contraintes soient respectés, corrigeant en partie le problème du manque de documentation des API actuelles.

Quand je lis: Les principaux mainteneurs du noyau sont plus habitués au langage C et veulent poursuivre sur cette lancée. Ils refusent donc de porter le code existant en Rust ou de passer du temps pour aider d’autres contributeurs à le porter en Rust. Je suis tout à fait d'accord avec eux.

Ce qui tombe bien, car on ne leur demande pas, même si certains se plaignent comme si c'était le cas

Les mainteneurs historique ne veulent pas aider d'autres contributeurs à le porter en Rust. Ils sont là pour coder ces vieux développeurs barbus, ils ne sont pas des instituteurs ou des formateurs pour expliquer à d'autres comme faire un portage vers un autre langage qu'une nouvelle génération veut utiliser.

On ne leur demande évidement pas non plus des cours magistraux de C. Les gens qui travaillent sur Rust4Linux connaissent bien évidement le C.

On parle ici des développeurs extrêmement expérimentés du noyaux. S'il considèrent que Rust n'apportent pas de plus-value significativement au kernel on peut quand même prendre leur opinion au sérieux, me semble-t-il ?

On peut les écouter attentivement, sans pour autant prendre tout ce qu'ils disent pour parole d'évangile. Je suis prêt a entendre que le Rust pourrait poser plus de problèmes qu'il apporte de solution, mais pour le moment les arguments avancés ne sont généralement pas pertinents. Particulièrement pour ceux qui sont virulents, j'entends plus une résistance de principe que de vrais arguments. Quand j'entends le mainteneur dire qu'il ne veut pas de la religion du Rust, je pense que c'est assez symptomatique de sa vision et qu'il défend lui même la religion du C sur une base plus dogmatique que pragmatique.

Voilà une partie très intéressante. Je reprend les chiffres donnés: 2288 en 20 ans. 2288/20 = 144,4. 15,9% de ces vulnérabilités à des problèmes lié au C (gestion mémoire, dépassement de tampons, allocation non libérées, accà des zones mémoire invalide ou libérée, etc)

15,9% c'est juste pour le dépassement de tampon, ce qui n'est qu'une partie des erreurs de sécurité mémoires. J'ai pas de chiffres dont je suis certain pour le cas particulier de Linux, mais de ce qu'on constate en général sur les grosses applications C on est généralement au dessus de 60% de failles majeures dues à la sécurité mémoire. Si on en crois ce site, sur les dernières années plus de 99% des failles sont dues à la sécurité mémoire.

Bien, certains benchmarks, disent que Rust. Mais de combien de % sont-elles plus "rapide" ? Pas de grand chose, et d'autres benchmarks disent le contraire.

En effet l'approche la plus correcte au niveau des performance, c'est de considérer que Rust et C sont en moyenne aussi rapides.

Une partie de ces "atouts" sont annihilés par le fait qu'il faut passer en mode "unsafe" pour certains accès au noyau. Et donc une partie de l'avantage de Rust s'évapore à cause de ce passage en mode "unsafe" qu'il est forcé d'utiliser à certains endroits.

L'existence du bloc unsafe n’annihile absolument pas tout l’intérêt de Rust. Le fait de contenir les risques de sécurité mémoire dans des petites sections clairement identifiées et donc plus facile a surveiller efficacement, reste un énorme avantage comparé à un langage qui est unsafe partout.

Je peux les comprendre... Quand il faut créer des "passerelles", ça ajoute une couche de complexité. Puisque ces "passerelles" sont apparement nécessaires pour l'introduction du code Rust dans le noyau, c'est à eux que revient cette chargent, et pour se faire, ils doivent être aussi compétant en C qu'en Rust.

Et c'est justement le cas.

Je ne connais pas ce projet @redox_os, mais s'il a fallut 30 ans pour que Linux soit ce qu'il est aujourd'hui, je doute fort que @redox_os le fasse en quelques années seulement.

Bien évidement qu'on ne va pas refaire Linux à l'identique avec 10 fois moins de temps et de contributeurs. Il n’empêche que Redox est d'une qualité surprenante au vu de son jeune age et de son équipe limitée. De là à dire que Rust peut aider à développer du code de qualité plus vite, il y a un pas que je ne franchirais pas encore, mais je laisse la question en suspens.

Faut-il comprendre que pour certaines parties, Rust ne fait pas le taf ?

Même Linux n'est pas 100% en C, il contient de l'assembleur.
A ma connaissance le noyau de Redox est bien en Rust et le bootloader est en assembleur. Bien évidement les applications de l'espace utilisateur ne sont pas toutes en Rust. Beaucoup sont des portages d'application C (GCC, make, curl, ...)

Quand au fait de parler de faire passer vos changements devant des mégalomanes pédants et condescendants (je redis que je ne connaît pas cette communauté), et que de cela découle le fait de créer un nouveau noyaux (ou OS complet, je ne sais pas), montre en tout cas très peu d'humilité, mais également un sentiment de supériorité face à des gens qui ont fait leurs preuves depuis 30 ans.

Ce n'est certainement qu'une des raisons qui l'ont poussé a créer Redox OS, qui n'est pas un Linux réécrit en Rust, mais un OS structurellement très différent. C'est un micro-kernel, qui a la base ne visait pas la compatibilité directe avec POSIX, bien qu'il semble changer sur ce point.

Pour le reste je vais pas répondre sur tout au point par point parce que c'est très long et certain trucs sont beaucoup trop confus, ce qui est n'est pas vraiment votre faute vu que vous commentez la série de petites citations de l'article qui manquent énormément de contexte.

Et bien qu'il continue son travail sur cet outils, qui, d'après lui même n'est pas terminé. Puis il pourra avancer.
C'est évident, mais cette charge de travail revient à ceux qui veulent introduire Rust, et donc à la communauté Rust

Encore une fois personne ne dit l'inverse. Le projet Rust4Linux essaie de mettre en place toute l'infrastructure pour qu'écrire un driver en Rust soit le plus naturel possible et s’intègre au mieux dans l'existant. Le statut est toujours expérimental et tout n'est pas encore prêt mais ça n’empêche pas le travail d'avancer sans avoir d'impact négatif sur les développeurs actuel, a par les inciter à mettre au clair les éléments actuellement mal documentés de l'API, ce qui est une bonne chose même pour les drivers C.

Ce processus de mise à niveau finira par s'arrêter et une version minimale de Rust sera définie une fois que les fonctionnalités importantes dont dépend le noyau se seront stabilisées.
Cest du bon sens. Le noyau linux ne peut pas être construit sur un langage qui évolue toujours en permanance. Rust n'est pas "prêt" actuellement, laissons-le se stabiliser avant de l'intégrer dans un si grand projet.

Rust est stable (dans le sens rétrocompatible) depuis presque 10 ans, mais il continue d'évoluer et n'a pas de raisons de s’arrêter. Ca n'est pas un problème, au contraire, vu qu'il manque encore certaines fonctionnalité pour s'intégrer plus efficacement au noyau.

Ojeda a déclaré qu'il travaillait à la recherche de ressources de développement pour gccrs ; le projet repose actuellement sur plus de 800 correctifs hors arborescence et a encore beaucoup de travail à faire en plus...
Il n'y a peut-être pas autant de développeurs compétant que de développeurs C compétant. Rust est encore jeune.

C'est un plutôt le contraire, gcc étant écrit en C++, y compris le nouveau frontend pour Rust en cours de développement. La difficulté c'est surtout qu'il faut des développeurs qui maitrisent les arcanes de gcc et motivés pour y ajouter un fontend en Rust. Le compilateur de référence ne manque pas de contributeurs compétants.

[OuftiBoy]

Bonjour Uther,

Et c'est exactement le cas. L'introduction de Rust a été faite de manière prudente en limitant Rust a des modules isolés. Les gens qui travaillent sur Rust4Linux ne demandent pas aux contributeurs qui ne sont pas intéressés par les modules en Rust de lire, ni d'écrire la moindre ligne de Rust.

A priori, la seule chose qui leur a été demandée c'est, dans certains cas, d'expliciter les règles que doivent actuellement respecter l'API des drivers, bref des choses qui sont de toute façon nécessaire pour faire des drivers C corrects et qui auraient dues être officiellement documentées. Le système de type de Rust permettra d'assurer que ces contraintes soient respectés, corrigeant en partie le problème du manque de documentation des API actuelles.

Je peux comprendre ce besoin de "documentation" manquante, mais ces vieux barbu ont su faire avec pendant 30 ans. Aucuns développeur que je connaisse n'aime écrire une doc. Je comprend donc qu'ils n'ait pas envie d'en écrire une pour d'autres. La meilleur documentation, c'est LE code.

Le problème c'est justement qu'on ne leur demande pas, mais certains se comportent comme si c'était le cas.

Tu dis : "A priori, la seule chose qui leur a été demandée c'est, dans certains cas, d'expliciter les règles que doivent actuellement respecter l'API des drivers". C'est de la doc, non ? Qu'ils aient besoins de ce genre de doc, c'est qu'ils ne comprennent pas le système en essayant de lire le code.

On ne leur demande évidement pas non plus des cours magistraux de C. Les gens qui travaillent sur Rust4Linux connaissent bien évidement le C.

Je suppose que oui, bien évidemment. Ce ne sont pas les derniers de la classe qui font ce genre de chose. J'ai franchement rien contre Rust, mais comme ce sont des "plus jeunes" qui poussent pour son intégration dans linux, ils devraient avoir le temps, l'énergie et l'envie d'apprendre et de comprendre la base de code C existante. Les anciens, qui vont bientôt passer la main, n'ont pas envie d'apprendre Rust pour expliquer clairement, via une doc, comment il faut faire.

On peut les écouter attentivement, sans pour autant prendre tout ce qu'ils disent pour parole d'évangile. Je suis prêt a entendre que le Rust pourrait poser plus de problèmes qu'il apporte de solution, mais pour le moment les arguments avancés ne généralement pas pertinents. Particulièrement pour ceux qui sont virulents, j'entends plus une résistance de principe que de vrais arguments. Quand j'entends le mainteneur dire qu'il ne veut pas de la religion du Rust, je pense que c'est assez symptomatique de sa vision et qu'il défend lui même la religion du C sur une base plus dogmatique que pragmatique.

Je suis d'accord avec toi, mais c'est un reflexe humain que je peux comprendre. Perso, je ne suis d'AUCUNE religion ou autres SECTE. Je pense que les arguments que j'ai avancé ne sont pas un signe de résistante. Le noyau linux, il peuvent le refaire en Basic si ça les amuse, j'en ai rien à battre.

15,9% c'est juste pour le dépassement de tampon, ce qui n'est qu'une partie des erreurs de sécurité mémoires. J'ai pas de chiffres dont je suis certain pour le cas particulier de Linux, mais de ce qu'on constate en général sur les grosses applications C on est généralement au dessus de 60% de failles majeures dues à la sécurité mémoire. Si on en crois ce site, sur les dernières années plus de 99% des failles sont dues à la sécurité mémoire.

Oui, dans d'autres projets, le C pose ce genre de soucis. Mais les développeurs du noyaux linux ne sont pas développeurs lambda, ce qui explique peut-être pourquoi il n'y a pas tant de faille que cela dans linux. Encore une fois, ce n'est pas qu'une question de langage, c'est de la bonne utilisation de ce langage que je parle, même si personne n'est à l'abris de faire une erreurs, même parmi les meilleurs.

Je comprends tout a fait les arguments pour que de nouveau projets soit fait en Rust, mais ici on ne parle pas d'un nouveau projet. On parle d'une immense base de code étalée sur 30 ans.

En effet l'approche la plus correcte au niveau des performance, c'est de considérer que Rust et C sont en moyenne aussi rapides.

On est bien d'accord

L'existence du bloc unsafe n’annihile absolument pas tout l’intérêt de Rust. Le fait de contenir les risques de sécurité mémoire dans des petites sections clairement identifiées et donc plus facile a surveiller efficacement, reste un énorme avantage comparé à un langage qui est unsafe partout.

Et c'est justement le cas.

Bien évidement qu'on ne va pas refaire Linux à l'identique avec 10 fois moins de temps et de contributeurs. Il n’empêche que Redox est d'une qualité surprenante au vu de son jeune age et de son équipe limitée. De là à dire que Rust peut aider à développer du code de qualité plus vite, il y a un pas que je ne franchirais pas encore, mais je laisse la question en suspens.

Je suis sur la même position. les bloc "unsafe" n'enlèvent pas tout les avantages de Rust, mais il en retire pas mal. Tu as toi même dit dans une réponse que "transmute" pouvait pose des soucis. Pour ce qui est de savoir si "Rust peut aider à développer du code de qualité plus vite", comme toi, je ne franchis pas le pas non plus, je n'ai pas assez de données en main.

Même Linux n'est pas 100% en C, il contient de l'assembleur. A ma connaissance le noyau de Redox est bien en Rust et le bootloader est en assembleur. Bien évidement les applications de l'espace utilisateur ne sont pas toutes en Rust. Beaucoup sont des portages d'application C (GCC, make, curl, ...)

Oui, impossible de se passer de l'assembleur pour certaines parties d'un noyau, et quand on sait s'en passé, le plus facile est de le faire en C. Linux tourne sur un diversité de machines, y'a-t-il un compilateur Rust pour toues ces architectures ? En tout cas, dans l'embarqué, le seul langage que tu es certains de retrouver, c'est le 'C'. C'est une réalité. Introduire Rust, c'est peut-être devoir abandonner certaines de ces architectures ?

Ce n'est certainement qu'une des raisons qui l'ont poussé a créer Redox OS, qui n'est pas un Linux réécrit en Rust, mais un OS structurellement très différent. C'est un micro-kernel, qui a la base ne visait pas la compatibilité directe avec POSIX, bien qu'il semble changer sur ce point.

Je ne connais rien de Rexox OS, mais s'ils étaient partis sur l'idée de ne pas avoir de compatibilité direct avec POSIX, et (comme tu le dis), qu'ils semblent changer sur ce point, c'est certainement car sans compatibilité POSIX, ils se privent d'une abondante quantité de code et/ou d'outils écrit en C.

Pour le reste je vais pas répondre sur tout au point par point parce que c'est très long et certain trucs sont beaucoup trop confus, ce qui est n'est pas vraiment votre faute vu que vous commentez la série de petites citations de l'article qui manquent énormément de contexte.

Oui, j'ai fais de mon mieux avec l'article de départ.

Encore une fois personne ne dit l'inverse. Le projet Rust4Linux essaie de mettre en place toute l'infrastructure pour qu'écrire un driver en Rust soit le plus naturel possible et s’intègre au mieux dans l'existant. Le statut est toujours expérimental et tout n'est pas encore prêt mais ça n’empêche pas le travail d'avancer sans avoir d'impact négatif sur les développeurs actuel, a par les inciter à mettre au clair les éléments actuellement mal documentés de l'API, ce qui est une bonne chose même pour les drivers C.

tu dis: "mettre en place toute l'infrastructure pour qu'écrire un driver en Rust soit le plus naturel possible et s’intègre au mieux dans l'existant", c'est une bonne idée, mais tu dis aussi que le status est toujours expérimental et que tout n'est pas encore prêt. Il faudra se pencher sur le problème quand ce ne sera plus expérimentale, mais tester/valider en commençant sur des projets 'C' de moindre envergure. Quant tu apprends à devenir alpiniste, tu ne t'attaque pas à l'Everest pour ta première expédition.

Rust est stable (dans le sens rétrocompatible) depuis presque 10 ans, mais il continue d'évoluer et n'a pas de raisons de s’arrêter. Ca n'est pas un problème, au contraire, vu qu'il manque encore certaines fonctionnalité pour s'intégrer plus efficacement au noyau.

Oui, Rust continue d'évoluer et de ce que j'ai lit, ça pose des soucis dans la chaine de construction du noyau.

Heu, s'il manque certaines fonctionnalités pour s'intégrer "efficacement" au noyau (après 10 ans), je comprend encore mieux les anciens développeurs C qui n'ont pas envie de faire joujou, avec un langage qui manque de fonctionnalités pour s'intégrer à leur noyau qu'ils ont construit depuis 30 ans, et qui n'ont pas envie de se mettre au Rust pour les quelques années qui leur reste.

C'est un plutôt le contraire, gcc étant écrit en C++, y compris le nouveau frontend pour Rust en cours de développement. La difficulté c'est surtout qu'il faut des développeurs qui maitrisent les arcanes de gcc et motivés pour y ajouter un fontend en Rust. Le compilateur de référence ne manque pas de contributeurs compétants.

Et bien, que la communauté Rust ajoute ce frontend en Rust. Il n'y a pas de développeurs C++ compétants dans le monde 'Rust' pour faire ce travail ? Pourquoi ce travail devraient-ils être fait par des gens qui n'en ont rien à battre de Rust ?

Juste une dernière petite choses

Je répète encore une fois que je n'ai rien contre Rust (à part le fait que je n'aime pas sa syntaxe, mais ça c'est un détail subjectif), mais il est plus "compliqué" que le C, beaucoup plus "jeune", et ça communauté n'est ni meilleur ni moins bonne qu'une autre.

Mais je remarque que cette communauté veux enter dans un projet 'C', avec leur langage 'Rust'. C'est donc à eux de s'adapter. Quand tu déménages dans un pays étranger, tu essayes de t'adapter aux coutumes de ce pays. Tu ne ne pas demande à ce pays de s'adapter aux tiennent. Si tu veux rentrer dans une mosquée, tu retires tes chaussures, car c'est ce que cette coutume implique.

Et pour en revenir à la documentation, je n'ai jamais (je dis bien jamais) eu besoin/envie/trouvé une documentation. Le plus simple, c'est de mettre les mains dans le cambouis, et de comprendre via le code source. Aucune doc ne reste à jour bien longtemps...

Excuse-moi, je remarque que je t'ai tutoyé. Mille excuses, mais vous/tu peux en faire de même pour moi, pas de soucis ;-)

BàT et Peace & Love.

[fdecode]

De là à dire que Rust peut aider à développer du code de qualité plus vite, il y a un pas que je ne franchirais pas encore, mais je laisse la question en suspens.

Moi j'ai franchi le pas. Quand je peux le faire contractuellement, je fais tous mes codes en Rust. Souvent, je travaille en petites équipes voire seul. La syntaxe contraignante de Rust et ses outils de généricité (et tout le reste) facilitent grandement la conception de projets complexes. On ne me croit pas quand je le dis, mais il y a des projets que j'ai mené en Rust et que je n'aurais même pas envisagé en C ou en C++. Par ailleurs, Rust démocratise des domaines de programmation délicats comme le multi-thread et l'asynchrone. J'avais bricolé des choses en C il y a très longtemps, j'avais fait du code plus sérieux en C# et en Scala, mais maintenant j'ai tendance à structurer d’amblé mes codes Rust en vue de versions multi-thread ou asynchrones.

[NotABread]

...
Oui, impossible de se passer de l'assembleur pour certaines parties d'un noyau, et quand on sait s'en passé, le plus facile est de le faire en C. Linux tourne sur un diversité de machines, y'a-t-il un compilateur Rust pour toues ces architectures ? En tout cas, dans l'embarqué, le seul langage que tu es certains de retrouver, c'est le 'C'. C'est une réalité. Introduire Rust, c'est peut-être devoir abandonner certaines de ces architectures ?
...

Il me semble que c'est une lacune que gccrs devrait combler puisqu'il s'agit d'écrire un front-end Rust à GCC.

[OuftiBoy]

Bonjour,

Il me semble que c'est une lacune que gccrs devrait combler puisqu'il s'agit d'écrire un front-end Rust à GCC.

Rien n'empêche (à ma connaissance) qu'un développeur Rust (ou une équipe Rust) ne fassent ce taf. S'ils estiment en avoir besoin, ils devraient le faire, et non attendre qu'un autre le fasse. J'ai du mal a comprendre, parce s'ils veulent qu'on adopte 'Rust', ils devraient tout faire pour que cela soit le moins douloureux possible pour ceux venant d'autres langages. Peut-être ne veulent-ils pas mettre les mains dans le cambouis du code C/C++ de GCC ? Je ne sais pas... Rust existe depuis 10 ans, et en 10ans, personne de la communauté 'Rust' n'a pu/voulu ajouter ce front-end Rust à GCC ? C'est assez troublant...

BàV et Peace & Love.

[NotABread]

Bonjour,



Rien n'empêche (à ma connaissance) qu'un développeur Rust (ou une équipe Rust) ne fassent ce taf. S'ils estiment en avoir besoin, ils devraient le faire, et non attendre qu'un autre le fasse. J'ai du mal a comprendre, parce s'ils veulent qu'on adopte 'Rust', ils devraient tout faire pour que cela soit le moins douloureux possible pour ceux venant d'autres langages. Peut-être ne veulent-ils pas mettre les mains dans le cambouis du code C/C++ de GCC ? Je ne sais pas... Rust existe depuis 10 ans, et en 10ans, personne de la communauté 'Rust' n'a pu/voulu ajouter ce front-end Rust à GCC ? C'est assez troublant...

BàV et Peace & Love.

Quatre raison expliquent pourquoi un front-end rust n'a pas été fait avant:
- le besoin est né du projet Rust for linux
- ça ne fait pas si longtemps que ça que Rust s'axe plus sur la stabilisation, ce qui permet de développer le front-end sans trop avoir à écrire de code qui sera rendu obsolète ou à revoir parce qu'une feature a changée
- ce ne sont pas les même équipes qui gère le compilateur Rust officiel (rustc) et GCC. Rustc est basé sur LLVM, pour faire gccrs, il faut créer les équivalents GCC des features LLVM dont le compilateur a besoin quand ceux-ci n'existe pas. Donc on ne parle pas de juste faire un addon à GCC mais de le rendre apte à accueillir un front-end Rust
- d'un point de vu pragmatique, la communauté Rust a plus besoin d'enrichir et maturer son écosystème que de développer des compilateurs alternatifs. Au doigt mouillé, les plateformes supportées par rustc doivent représenter plus de 95% des configuration. La liste exacte des plateformes supportées:

aarch64-apple-darwin
aarch64-pc-windows-msvc
aarch64-unknown-linux-gnu
aarch64-unknown-linux-musl
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
armv7-unknown-linux-gnueabihf
i686-pc-windows-gnu
i686-pc-windows-msvc
i686-unknown-linux-gnu
loongarch64-unknown-linux-gnu
powerpc64le-unknown-linux-gnu
powerpc64-unknown-linux-gnu
powerpc-unknown-linux-gnu
riscv64gc-unknown-linux-gnu
s390x-unknown-linux-gnu
x86_64-apple-darwin
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc
x86_64-unknown-freebsd
x86_64-unknown-illumos
x86_64-unknown-linux-gnu
x86_64-unknown-linux-musl
x86_64-unknown-netbsd

La Rust foundation coopère avec l'équipe de gccrs et il y a aussi des contributeurs externes au projet, donc ça avance

[fdecode]

- d'un point de vu pragmatique, la communauté Rust a plus besoin d'enrichir et maturer son écosystème que de développer des compilateurs alternatifs. Au doigt mouillé, les plateformes supportées par rustc doivent représenter plus de 95% des configuration. La liste exacte des plateformes supportées:

Et l'utilisation de LLVM aide à la portabilité.

[OuftiBoy]

Quatre raison expliquent pourquoi un front-end rust n'a pas été fait avant:
- le besoin est né du projet Rust for linux
- ça ne fait pas si longtemps que ça que Rust s'axe plus sur la stabilisation, ce qui permet de développer le front-end sans trop avoir à écrire de code qui sera rendu obsolète ou à revoir parce qu'une feature a changée

C'est bien ce que je dis, "Rust" évolue toujours beaucoup trop, que pour prendre le danger de l'introduire dans une large base de code en C qu'est linux.

ce ne sont pas les même équipes qui gère le compilateur Rust officiel (rustc) et GCC. Rustc est basé sur LLVM, pour faire gccrs, il faut créer les équivalents GCC des features LLVM dont le compilateur a besoin quand ceux-ci n'existe pas. Donc on ne parle pas de juste faire un addon à GCC mais de le rendre apte à accueillir un front-end Rust

Heu, ça me laisse perplexe, qu'a Rust de si différents que d'autres langages, qu'il faut modifié GCC pour qu'on puisse produire un front-end ?

- d'un point de vu pragmatique, la communauté Rust a plus besoin d'enrichir et maturer son écosystème que de développer des compilateurs alternatifs.

Et bien qu'ils maturent et enrichisent leur écosystème. Si ce n'est pas une priorité pour cette communauté d'être supporté par GCC, ils ne doivent pas espérer que quelqu'un d'autre le fasse pour eux. Donc, "Rust" n'est pas "prêt" pour être intégré facilement dans GCC et donc dans Linux.

Au doigt mouillé, les plateformes supportées par rustc doivent représenter plus de 95% des configuration. La liste exacte des plateformes supportées:

aarch64-apple-darwin
aarch64-pc-windows-msvc
aarch64-unknown-linux-gnu
aarch64-unknown-linux-musl
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
armv7-unknown-linux-gnueabihf
i686-pc-windows-gnu
i686-pc-windows-msvc
i686-unknown-linux-gnu
loongarch64-unknown-linux-gnu
powerpc64le-unknown-linux-gnu
powerpc64-unknown-linux-gnu
powerpc-unknown-linux-gnu
riscv64gc-unknown-linux-gnu
s390x-unknown-linux-gnu
x86_64-apple-darwin
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc
x86_64-unknown-freebsd
x86_64-unknown-illumos
x86_64-unknown-linux-gnu
x86_64-unknown-linux-musl
x86_64-unknown-netbsd

La Rust foundation coopère avec l'équipe de gccrs et il y a aussi des contributeurs externes au projet, donc ça avance

Heu, ta liste peut sembler impressionnante, mais y'a rien pour les milliers de petits µControlleur, où il n'y a que le C. C'est le gros avantage du C, il est partout, toujours disponible, facile a apprendre et a maîtriser, pour peu qu'on fasse un petit effort... Mais l'effort, c'est pas dans l'air du temps...

- ce ne sont pas les même équipes qui gère le compilateur Rust officiel (rustc) et GCC. Rustc est basé sur LLVM, pour faire gccrs, il faut créer les équivalents GCC des features LLVM dont le compilateur a besoin quand ceux-ci n'existe pas. Donc on ne parle pas de juste faire un addon à GCC mais de le rendre apte à accueillir un front-end Rust

Bien, c'est à la communauté Rust de faire ce taf.

BàT et Peace & Love.

[Uther]

Je peux comprendre ce besoin de "documentation" manquante, mais ces vieux barbu ont su faire avec pendant 30 ans. Aucuns développeur que je connaisse n'aime écrire une doc. Je comprend donc qu'ils n'ait pas envie d'en écrire une pour d'autres. La meilleur documentation, c'est LE code.

Il s'agit juste de demander des renseignement à ceux qui sont censées les connaitre, ça ne devrait pas les occuper bien longtemps. Si cette connaissance a été perdue et qu'il faut reverse-engineer à partir du code, en effet, c'est à l’équipe de Rust for Linux de le faire elle même. Mais pour le coup c'est un sacré boulot qu'on ne devrait pas avoir à refaire a chaque fois qu'on va créer un nouveau driver. J'ose espérer que ce n'est pas la manière normale de faire et qu'il y a un minimum de capitalisation de la connaissance dans la communauté Linux.

Oui, dans d'autres projets, le C pose ce genre de soucis. Mais les développeurs du noyaux linux ne sont pas développeurs lambda, ce qui explique peut-être pourquoi il n'y a pas tant de faille que cela dans linux. Encore une fois, ce n'est pas qu'une question de langage, c'est de la bonne utilisation de ce langage que je parle, même si personne n'est à l'abris de faire une erreurs, même parmi les meilleurs.

Sauf que non, les développeurs du noyau Linux n'ont rien de surhumain. Il suffit de regarder les lisings de CVE pour voir qu'il y a pas mal de vulnérabilité relevées dans Linux, en grande majorité due a des erreurs mémoires.

Je comprends tout a fait les arguments pour que de nouveau projets soit fait en Rust, mais ici on ne parle pas d'un nouveau projet. On parle d'une immense base de code étalée sur 30 ans.

Pour la dixième fois (a peu près) : on ne parle pas de réécrire tout Linux mais de permettre d'écrire de nouveaux drivers en Rust.

Je suis sur la même position. les bloc "unsafe" n'enlèvent pas tout les avantages de Rust, mais il en retire pas mal. Tu as toi même dit dans une réponse que "transmute" pouvait pose des soucis. Pour ce qui est de savoir si "Rust peut aider à développer du code de qualité plus vite", comme toi, je ne franchis pas le pas non plus, je n'ai pas assez de données en main.

Je ne dirais pas que le bloc unsafe retire tant de garanties que ça. Les garanties apportées par Rust restent valides sur la très grande majorité du code. Oui il faut être particulièrement prudent à ce que l'on fait dans les bloc unsafe, mais ils restent normalement exceptionnels et le fait qu'ils soient marqué comme tel, fait qu'on sait où concentrer la relecture.

Oui, impossible de se passer de l'assembleur pour certaines parties d'un noyau, et quand on sait s'en passé, le plus facile est de le faire en C. Linux tourne sur un diversité de machines, y'a-t-il un compilateur Rust pour toues ces architectures ? En tout cas, dans l'embarqué, le seul langage que tu es certains de retrouver, c'est le 'C'. C'est une réalité. Introduire Rust, c'est peut-être devoir abandonner certaines de ces architectures ?

Pour le moment on a en est juste a ajouter des nouveaux drivers expérimentaux, principalement pour du matériel qui tourne sur des machines récentes supportées par le compilateur Rust.
Si un jour on veut remplacer les driver C actuels par des drivers en Rust ça deviendrait un problème, mais on y est pas encore. D'ici là, il est probable qu'au moins un des deux projets en cours qui visent a avoir un compilateur Rust avec un backend GCC soit fonctionnel.

tu dis: "mettre en place toute l'infrastructure pour qu'écrire un driver en Rust soit le plus naturel possible et s’intègre au mieux dans l'existant", c'est une bonne idée, mais tu dis aussi que le status est toujours expérimental et que tout n'est pas encore prêt. Il faudra se pencher sur le problème quand ce ne sera plus expérimentale, mais tester/valider en commençant sur des projets 'C' de moindre envergure. Quant tu apprends à devenir alpiniste, tu ne t'attaque pas à l'Everest pour ta première expédition.

Oui mais pour le coup un alpiniste ne s'entraine pas dans les escaliers. Rust est un langage globalement adapté, on le sait, mais au bout d'un moment il faut s'attaquer au vrai problème pour avancer. Le fait que le projet Rust for Linux tourne soit intégré à Linux, a permis d'identifier les problèmes qui sont en cours de correction.
Le projet restant optionnel : on peut toujours construire un noyau Linux sans Rust.

Heu, s'il manque certaines fonctionnalités pour s'intégrer "efficacement" au noyau (après 10 ans), je comprend encore mieux les anciens développeurs C qui n'ont pas envie de faire joujou, avec un langage qui manque de fonctionnalités pour s'intégrer à leur noyau qu'ils ont construit depuis 30 ans, et qui n'ont pas envie de se mettre au Rust pour les quelques années qui leur reste.

Pour la onzième fois (à peu près), on ne force à personne à se mettre au Rust. On permet juste a ceux qui le veulent d'expérimenter l'introduction de Rust dans les drivers. Linux c'est construit autour de ce que permettait C pendant 30 ans. C'est normal qu'un langage qui arrive en cours de route ait besoin de travail pour s'intégrer a l'existant, c'est le travail qui est en cours.

Et bien, que la communauté Rust ajoute ce frontend en Rust. Il n'y a pas de développeurs C++ compétants dans le monde 'Rust' pour faire ce travail ? Pourquoi ce travail devraient-ils être fait par des gens qui n'en ont rien à battre de Rust ?

Pour la douzième fois (à peu près), on exige rien à ce niveau non plus des gens qui travaillent sur le noyau Linux.
Il y a deux projet actuellement en cours avec des gens qui n'ont rien a voir avec le noyau Linux et qui travaillent là dessus, parce que ça les intéresse. Mais faire un compilateur, ça tombe pas du ciel, c'est techniquement aussi complexe que faire un OS, voire plus quand on travaille sur des compilateurs du niveau de GCC.
Il y a actuellement deux projets avec deux approches différentes :

• Gccrs vise ajouter un frontend Rust à GCC. Il plait d'avantage aux Linuxiens qui ont l'habitude de travailler avec GCC mais il est techniquement complexe a mettre en œuvre, vu qu'il faut refaire un compilateur Rust de zero en s'adaptant a la façon de fonctionner de GCC.
• Rust_gcc_codegen vise a brancher le backend de GCC sur le compilateur Rust existant. Il avance bien plus vite vu que toute la partie front-end et back-end existent déjà, il s'agit juste de faire l'interface entre les deux, ce qui reste quand même complexe. Il est déjà capable de compiler du vrai code Rust.

Mais je remarque que cette communauté veux enter dans un projet 'C', avec leur langage 'Rust'. C'est donc à eux de s'adapter. Quand tu déménages dans un pays étranger, tu essayes de t'adapter aux coutumes de ce pays. Tu ne ne pas demande à ce pays de s'adapter aux tiennent. Si tu veux rentrer dans une mosquée, tu retires tes chaussures, car c'est ce que cette coutume implique.

Pour la treizième fois (à peu près), les gens du projet Rust for Linux n'exigent rien des développeurs Linux actuels.
Pour continuer l’analogie, on est dans le cas d'un étranger qui fait tout ce qu'il faut pour s'intégrer mais qui est quand même victime de racisme.

Excuse-moi, je remarque que je t'ai tutoyé. Mille excuses, mais vous/tu peux en faire de même pour moi, pas de soucis ;-)

Pas de soucis, moi aussi sur le forum j'ai tendance a passer du tutoiement au vouvoiement, et inversement, sans m'en rendre compte.

Moi j'ai franchi le pas. Quand je peux le faire contractuellement, je fais tous mes codes en Rust. Souvent, je travaille en petites équipes voire seul. La syntaxe contraignante de Rust et ses outils de généricité (et tout le reste) facilitent grandement la conception de projets complexes. On ne me croit pas quand je le dis, mais il y a des projets que j'ai mené en Rust et que je n'aurais même pas envisagé en C ou en C++. Par ailleurs, Rust démocratise des domaines de programmation délicats comme le multi-thread et l'asynchrone. J'avais bricolé des choses en C il y a très longtemps, j'avais fait du code plus sérieux en C# et en Scala, mais maintenant j'ai tendance à structurer d’amblé mes codes Rust en vue de versions multi-thread ou asynchrones.

Oui j'ai oublié de préciser que je parlais dans le contexte du développement d'OS où on a pas encore assez de retour pour être absolument formel. Mais de manière globale je suis totalement d'accord avec votre point de vue.

C'est bien ce que je dis, "Rust" évolue toujours beaucoup trop, que pour prendre le danger de l'introduire dans une large base de code en C qu'est linux.

Il évolue, mais de manière rétrocompatible donc pas vraiment dangereuse.

Heu, ça me laisse perplexe, qu'a Rust de si différents que d'autres langages, qu'il faut modifié GCC pour qu'on puisse produire un front-end ?

En gros, pas grand chose. De ce que je vois en suivant les rapport d'avancement de rust_codegen_gcc, le back-end gcc est globalement adapté, il y a juste des petits patchs nécessaires pour bien gérer certains détails.

Heu, ta liste peut sembler impressionnante, mais y'a rien pour les milliers de petits µControlleur, où il n'y a que le C.

Ce n'est que la liste des cibles dites de tiers 1, dont le projet Rust garantit lui même un support complet. Si on rajoute les cible Tiers 2 et Tiers 3 ça fait plus. De plus Linux n'est de toute façon pas capable de fonctionner sur tous les microcontrôleurs que tu évoques.
Si on fait le croisement entre les cibles que Linux supporte et celles que le compilateur Rust actuel supporte, il ne doit pas en manquer tant que ça.

C'est le gros avantage du C, il est partout, toujours disponible, facile a apprendre et a maîtriser, pour peu qu'on fasse un petit effort... Mais l'effort, c'est pas dans l'air du temps.

Si c'était le cas Rust ne serait pas a la mode, car il faut plus d'efforts pour maitriser le Rust que le C.

[floyer]

Heu, ça me laisse perplexe, qu'a Rust de si différents que d'autres langages, qu'il faut modifié GCC pour qu'on puisse produire un front-end ?

Le problème n’est pas sur les spécificités de Rust mais sur les différences des back-end LLVM et GCC.

Rustc est construit pour LLVM, donc l’adapter pour GCC présente un effort. Une alternative est d’adapter GCC pour que son back-end ressemble plus à LLVM. Le même effort serait nécessaire pour tout langage.