--
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
--
En effet, pris le cas de Platon car c'est une occurrence très ancienne et très connue, mais de tout temps on c'est plaint de la décadence de la jeunesse.Envoyé par fdecode
Je me garderais bien de conclure quoique ce soit là dessus. C'est facile de tordre ce genre de discours dans le sens que l'on veut quand on on choisit à posteriori ce qui nous intéresse.
Athènes a été prise plusieurs fois dans son histoire que ce soit avant ou après Platon.
Bien entendu, et cela se comprend dans les deux sens.
Mais il y a des indicateurs objectifs qui laissent peu de place au doute.
Par exemple en mathématiques:
https://timss2023.org/results/math-achievement/
Au chapitre "objectivité":
Source: https://www.forbes.com/sites/duncanm...-in-the-world/
Ici, le classement semble cumulatif. Cela défavorise l'Asie, et autres pays émergents.
Il y a PISA aussi. La presse avait évoqué la chute française inédite de 2022, mais cela m'avait semblé moins marqué que les résultats de TIMSS.
Bonne remarque, mais si on est capable d'utiliser l'IA pour fournir un meilleur code, on peut le faire aussi en C, donc pas besoin de Rust dans ce cas là.Il ne s’agit pas de vérifier si le code compile, mais si l’IA est capable de fournir une preuve formelle de la conformité du code à des spécifications de haut niveau.
Intégrer Rust dans le noyau Linux, si ça apporte un vrai plus. Pour le moment c'est un peu tôt pour en juger.
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Consultez nos FAQ : Windows, Linux, Virtualisation
« Le problème vient peut-être de vous », lance Linus Torvalds à un promoteur de Rust dans le noyau Linux
« Le problème vient peut-être de vous », lance Linus Torvalds à un promoteur de Rust dans le noyau Linux
Linus Torvalds s’immisce dans la rixe qui oppose mainteneurs C et Rust
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. L’état des lieux à date fait état de ce que le taux d’adoption de Rust comme langage de programmation pour le noyau Linux reste faible. C’est la raison pour laquelle des promoteurs de Rust comme langage de développement du noyau Linux bousculent en utilisant des méthodes que Linus Torvalds juge malsaines pour la communauté. C’est la raison d’une récente sortie de ce dernier contre Hector Martin qui promeut l’usage de Rust comme langage de développement du noyau Linux.
« Et si vous acceptiez le fait que le problème vient peut-être de vous ? Vous pensez que vous savez mieux [que les autres]. Mais le processus actuel fonctionne. Il a des problèmes, mais les problèmes font partie de la vie. La perfection n’existe pas », lance-t-il à Hector Martin auquel il reproche en particulier sa propension à communiquer sur les réseaux sociaux à propos des écueils en matière d’adoption de Rust dans le noyau Linux plutôt que dans les canaux consacrés par la communauté de développement du kernel.
Le différend est né de l'opposition de Hellwig (mainteneur principal du noyau) à un correctif proposé le mois dernier par Hector Martin et qui devait permettre aux pilotes de périphériques écrits en Rust d'appeler l'API DMA du noyau, principalement basé sur le langage C, qui alloue et mappe des régions de mémoire pour l'accès direct à la mémoire.
Les habitués du langage C n’entendent pas se laisser embarquer dans ce qu’ils appellent la nouvelle religion du RustRust for Linux drama
— 🐝🇬🇷 (@bee_fumo) February 4, 2025
It is in reference to Rust DMA abstractions.
Not gonna lie i get the argument.
(also hector martin is putting words in people's mouths)https://t.co/5QoVjvnJVD pic.twitter.com/Zvp4wpraA9
En adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit les 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. Mais les habitués du langage C désapprouvent l'initiative et n’entendent pas se laisser embarquer dans ce qu’ils appellent la nouvelle religion du Rust.
En réponse à Miguel Ojeda, Christoph Hellwig a déclaré : « gardez les wrappers dans votre code au lieu de rendre la vie difficile aux autres », et a poursuivi en affirmant que « les interfaces de l'API DMA devraient rester dans un code C lisible et non dans des bindings bizarres afin qu'il [reste] greppable et maintenable ».
Le souhait de Christoph Hellwig semble être que les pilotes qui ne sont pas écrits en C aient leurs propres liaisons privées avec le code C, et que ces abstractions ne soient pas maintenues séparément, pas même dans l'arbre rust/kernel. Interrogé par Danilo Krummrich, un ingénieur logiciel de Red Hat impliqué dans le projet Rust for Linux, Christoph Hellwig a clairement fait savoir qu'il n'est tout simplement pas intéressé par le code Rust :
« Ne me forcez pas à travailler avec votre langage brillant du jour. La maintenance de projets multilingues est une tâche pénible à laquelle je n'ai aucune envie de m'atteler. Si vous voulez utiliser quelque chose qui n'est pas du C, que ce soit de l'assembleur ou du Rust, vous écrivez dans des interfaces C et vous vous occupez vous-même du décalage d'impédance en ce qui me concerne », a-t-il lancé.
En réponse, Danilo Krummrich a expliqué que Rust for Linux crée un code Rust qui abstrait les API C pour tous les pilotes Rust et qui est maintenu par les développeurs Rust. En d'autres termes, le côté C du noyau reste le même, et les pilotes Rust utilisent des abstractions de ce code C, et ces abstractions sont maintenues par une équipe centralisée dans rust/kernel, ce qui est sans doute mieux que des pilotes ayant leurs propres bindings C individuels.
Mais Christoph Hellwig ne semble pas intéressé par le fait que les abstractions DMA Rust soient maintenues séparément. Christoph Hellwig a expliqué qu'il ne voulait pas d'un autre mainteneur. Il a poursuivi en affirmant que le fait de demander à d'autres de maintenir la couche d'abstraction Rust pour l'allocateur cohérent DMA en tant que composant séparé n'améliore pas les choses et entrave la maintenabilité du noyau Linux :
« Si vous voulez rendre Linux impossible à maintenir à cause d'une base de code interlangage, faites-le dans votre pilote pour que vous ayez à le faire au lieu de répandre ce cancer dans les sous-systèmes centraux. (Où ce cancer est explicitement une base de code interlangage et non Rust lui-même, juste pour échapper à la brigade flameware.)
Chaque bit supplémentaire introduit par un autre langage réduit considérablement la maintenabilité du noyau en tant que projet intégré. La seule raison pour laquelle Linux a réussi à survivre aussi longtemps est qu'il n'a pas de frontières internes, et l'ajout d'un autre langage rompt complètement avec cela.
Vous n'aimerez peut-être pas ma réponse, mais je ferai tout ce qui est en mon pouvoir pour arrêter cela. Ce n'est pas parce que je déteste Rust. Même si ce n'est pas mon langage préféré, c'est certainement l'un des meilleurs nouveaux langages et j'encourage les gens à l'utiliser pour de nouveaux projets là où il convient.
Je ne veux pas qu'il s'approche d'une énorme base de code C que je dois maintenir », a-t-il ajouté.
Source : LKML
Et vous ?
Voir aussi :
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
Oui, effectivement… je pense que l’on peut plus facilement faire confiance au code de SeL4 (dont la compilation finale est en C) qu’à un code Rust sans élément de preuve.
Ceci-dit, je pense que l’horizon d’une preuve automatique est un peu loin. Rust garde alors une utilité.
Bon vu que c'est vraiment d'actualité, si Rust est si intéressant que ça face au C, qu'il utilise l'IA pour avoir un équivalent optimisé du C en Rust....de toute façon on peut imaginer que le futur de l'IA, on pourra générer tout un OS.... ça peut paraïtre surréaliste au moment où j'écris mais c'est très loin d'être de la science fiction aussi....et penser le contraire ça serait ne pas admettre et ne pas croire à l'évolution de l'IA (générative)
La transpilation n’est pas de la science fiction. Je suppose que si Rust compile directement en LM, c’est par efficacité. Usuellement, on transpile en C par simplification et portabilité, mais avec des bibliothèques telles que LLVM, ce n’est plus forcément nécessaire.
Par ailleurs, quel intérêt vu de la maintenance d’avoir du C en intermédiaire ? La maintenance se fait toujours sur le code source, donc par définition, pas sur du code généré.
Du coup on arrête tout et on attend le futur ?
La jeunesse...
Oui, le PISA a été largement évoqué. Mais au-delà des indicateurs, il faudrait expliquer aux Français pourquoi leurs enfants deviennent plus sots que les autres. En Suisse, nous constatons tous les jours, avec effroi et consternation, pourquoi.
Que pensent les développeurs du noyau Linux de Rust ? La communauté du noyau Linux est divisée
Que pensent les développeurs du noyau Linux de Rust ? Le langage est pour d'aucuns une opportunité de combler les faiblesses du C en sécurisation de la mémoire des logiciels
Et un cancer pour 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. L’état des lieux à date fait état de ce que le taux d’adoption de Rust comme langage de programmation pour le noyau Linux reste faible. La situation est telle que l’intégration de Rust comme langage additionnel de développement du noyau au côté du C est sujette à controverse. La communauté de développement du kernel vibre au rythme de divergences d’opinions dans les rangs des mainteneurs.
« À mon avis, Rust est la plus grande avancée dans les langages de programmation de systèmes depuis des décennies, peut-être depuis C », selon le mainteneur Kent Overstreet
« La première chose qui devait être résolue, pour les langages systèmes, était une vérification efficace et pratique des références mémoire : d'où le borrow checker, qui fait partie du système de types de Rust. Cela résout immédiatement le plus gros problème du C, et améliore même d'autres langages à mémoire sûre en contraignant les effets secondaires (références mutables ^ partagées) d'une manière qui nous permet d'obtenir certaines des propriétés souhaitables des langages fonctionnels purs », ajoute-t-il à propos de l’un des éléments (le borrow checker) sur lequel repose la démarcation de Rust par rapport au C en matière de sécurisation des espaces mémoire.
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.
C’est là qu’intervient le langage Rust considéré par des acteurs de la filière comme le futur de la programmation système en lieu et place du langage C ou encore comme la meilleure chance de l’industrie informatique pour la mise sur pied d’applications système sécurisées. Chez Amazon par exemple, on est d’avis que « choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C, mais une efficacité énergétique et une performance d’exécution que seul le C offre. »
En effet, 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++.
Ainsi, en adoptant Rust, la communauté autour du noyau Linux entend 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.
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.
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.
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é.
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.
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.
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.
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é.
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.
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.
Source : Avis des mainteneurs
Et vous ?
Voir aussi :
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
Je cite...
À mon avis, Rust est la plus grande avancée dans les langages de programmation de systèmes depuis des décennies, peut-être depuis C
N'y aurait-il pas Ada en 1983 qui était fort novateur à l'époque (généricité bien avant les templates C++, exceptions, multitasking, rendez-vous, etc...), avec des FFI normalisées avec C, Fortran et COBOL, tout en permettant des accès bas niveaux pour ne pas dire très bas niveaux. Sans pour autant obliger à être systématiquement de bas niveau (On écriraplutôt que
Code : Sélectionner tout - Visualiser dans une fenêtre à part Ptr_A := new Integer;).
Code : Sélectionner tout - Visualiser dans une fenêtre à part ptr_a = (int*)malloc(sizeof(int));
A titre d'exemple, on peut indiquer l'adresse physique d'une variable.
Rares sont les langages qui permettent de descendre aussi bas. En C, il faudrait contourner avec un pointeur :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
D'ailleurs, on trouve plusieurs systèmes d'exploitation écrit en Ada : https://stackoverflow.com/questions/...-system-in-ada
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Je suis persuadé que ce qui a nuit le plus à Ada n'est pas les défauts du language, mais des considérations extérieures (coût des compilateurs exorbitant avant 1992 sortie de Gnat, puis ensuite les habitudes prises par la profession).
Je ne connais pas Ada.
Qu'est-ce que ça change fondamentalement de passer par des pointeurs plutôt que d'assigner une adresse à une variable?
Faut-il allouer cette mémoire avant? (je suppose que oui...)
Ada était élégante... et ce genre d'assignations avait certainement du sense à une époque où la mémoire était limitée et coûtait une fortune.
En 2025, il faut des langages tels que Rust.
Cela illustre les capacités bas niveau d'Ada - et donc à la programmation système, malgré des aspects haut-niveaux dont d'autres langages n'ont hérité qu'après. Dis autrement, Rust n'est pas le premier langage de programmation système novateur après C.
Allouer la mémoire ? Pas vraiment. Dans la programmation système, il peut y avoir des registres de cartes entrée/sortie mappés en mémoire (un peu moins vrai sur Intel avec les instructions IN et OUT qui tapent ailleurs, sur des ports).
Ceci-dit, c'est plus efficace d'avoir une variable mappée à une adresse que de passer par un pointeur. Compare :
et
Code : Sélectionner tout - Visualiser dans une fenêtre à part MOV ma_variable, AX
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
L'idée est plutôt d'illustrer qu'Ada est un langage de programmation système. Après, c'est sûr que le concept de Rust est de prendre toutes les bonnes choses qui existe. On trouvera dans Ada les exceptions, les types numériques avancés (range, virgule fixe par exemple)... et en Rust, les règles d'emprunt, les macros... Difficile de comparer.
Ada n'a pas percé. Peu de gens doivent le connaitre ici.N'y aurait-il pas Ada en 1983 qui était fort novateur à l'époque
Mais il n'y a pas forcément de lien entre la popularité de quelque chose et sa valeur pertinente.
L'avenir dira ce qu'il en est pour Rust.
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Surtout en informatique.
Une raison qui a empêché Ada de percer était le prix exorbitant des compilateurs qui le limitait à des applications critiques. Ce n'est plus le cas depuis 1992 (sortie du compilateur Gnat, gratuit), mais entre temps, la profession a pris d'autres habitudes (sauf celles travaillant dans la programmation de systèmes critique). De plus, lorsque l'on programme, on dépend d'un eco-système. Turbo-Pascal avait beaucoup de succès à l'époque de MS-DOS... et beaucoup moins à l'arrivée de Windows (si à chaque fois que Microsoft met à jour son SDK, il faut attendre une mise à jour du compilateur, cela limite...). Inversement, JavaScript tient une grande partie de son succès parce qu'il est nativement supporté par les navigateurs, ce qui ne laisse côté client que le choix entre JavaScript et des langages qui se transpilent en JavaScript (TypeScript, ReScript, OCaml...). WASM ouvre des possibilités cependant.
Cet aspect ecosystème est assez important et justifie les gestionnaire de package de bibliothèques (Cargo pour Rust, Vcpkg pour C++/Windows, Opam pour OCaml, Alire pour Ada, PIP pour Python, etc.)
Répondre avec citation
Partager