Il vont taper make au lieu de make…Envoyé par 23JFK
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 :
Il vont taper make au lieu de make…
Il se raconte que la communauté Rust est imbuvable et arrogante (un peu en mode nous sommes l'avenir - mais avenir qui n'arrive pas vraiment à faire ses preuves). Je ne sais pas vraiment ce qu'il en est, mais ce dont je suis est certain, c'est que mélanger deux langages aussi différents pour un projet aussi complexe et dont le but est l'accessibilité open-source est absurde d'autant que les promesses de sécurité améliorées ne sont pas vraiment au rendez-vous et probablement plus théorique que réelle (de mon point de vue) quand il faut être au plus près du hardware. Au niveau kernel, il n'y a de place que pour un seul langage (ou deux langages très semblables type C/C++). Si l'objectif était de faire une transition douce en remplaçant progressivement du C par du Rust, ça ne peut pas fonctionner et un mix éternel ne sera pas viable. Ça va finir par un fork du kernel où il y aura une version 100% en C, et une version à x% de Rust en progression... fragile.
Ça pourrait ne pas être aussi simple.
C'est vrai qu'une partie de la communauté Rust peut parfois être un trop enthousiaste et certains le déclarent un peu trop vite comme le langage inéluctable de l'avenir. Mais la majorité de la communauté ne soutient pas ça et travaille à limiter la diffusion de ce genre de propos. Il y a notamment des règles dans les canaux de discussion officiels contre ce genre de prosélytisme.
Mais en matière d'imbuvabilité et d'arrogance, la communauté Rust n'a absolument rien à envier aux communautés C et C++, qui à l'inverse se targuent bien trop souvent d'être les gardiennes du temple du bas niveau, qu'elles seules ont le droit de cité dans le domaine, et critiquent Rust souvent sans en savoir grand chose. Et pour le coup il ne semble pas y avoir beaucoup de volonté pour modérer ce genre de propos.
Dire que les promesses de sécurité ne sont pas au rendez-vous, c'est juste votre jugement personnel au doigt mouillé qui ne coïncide pas avec le mien.
Du peu de faits qu'on a pu constater pour le moment, il n'y a pas encore eu de problèmes mémoire remonté dans les drivers Linux écrits en Rust et selon les retours de Ashai Lina, la développeuse qui maintient le plus gros driver Rust pour le moment (GPU pour Apple Silicon), le langage l'a énormément aidée à développer rapidement du code de qualité. Évidement ça reste beaucoup trop tôt pour tirer des conclusions formelles dans un sens comme dans l'autre..
Tant qu'on garde une séparation claire avec une API bien définie, il n'y a pas vraiment de soucis. Seul les drivers peuvent être écrits en Rust, le cœur du noyau reste en C, et il n'y a aucun plan pour changer ça. Si un jour on voulait introduire du Rust dans le noyau lui même, la situation serait en effet compliquée, mais rien de tel n'est prévu.
Pour le moment si, en tout cas pour lancer la compilation, ça ne change rien foncièrement si on utilise pas de drivers en Rust.
Évidement si on veut activer des drivers en Rust, ça pousse à rajouter le compilateur à la chaine d'outils, mais pour le coup elle contient déjà entre autre Perl et OpenSLL, donc on peut pas dire que le problème de bloat de la chaine soit nouveau.
Avec un Makefile bien fait, tu peux compiler un logiciel développé avec différents langages sans problème. Linux est en C et en assembleur et pourtant un simple make suffit à le compiler sans te soucier du fait qu’il y a deux (maintenant 3) langages. (Voire un de plus avec les Kconfig qu’il faut interpréter)
Pour Rust au cœur du noyau ? Il semble que Rust dispose de pas mal de constructions permettant de s’interfacer avec du C, et ce de manière plus simple que d’autres langages et leur FFI.
Mais pour éviter de dupliquer les efforts, il faudrait utiliser cbindgen… pas sûr qu’il fonctionne bien avec les header Linux… à tester…
Rust permet en effet de s'interfacer avec du C mais pas aussi simplement qu'avec du C++, qui lui même n'est pas 100% transparent. Même si des outils comme bindgen et cbindgen peuvent aider, il reste pas mal de problèmes éventuels.
Les premiers exemples de problèmes qui me viennent en tête (c'est évidement loin d'être exhaustif)
- le typage avancé de Rust dont certaines propriétés sont perdues quand on passe au C
- certains choix pertinent dans un langage le sont moins quand on passe à l'autre. Par exemple en Rust il arrive qu'on utilise une référence à un objet car le borrow checker assure sa validité, alors qu'en C on aurait fait une copie pour éviter les risques.
- si l'interface entre les parties en C et en Rust doit être modifiée trop souvent (et il me semble avoir lu qu'il y a régulièrement des changements internes), ça va être lourd à maintenir.
Pour que ça se fasse bien, il faudrait au minimum que tous les développeurs noyaux soient tous de très bons développeurs C et Rust.
L'avantage de limiter Rust aux drivers c'est que c'est des modules qui n'ont pas impact direct sur le code noyau et qui ne sont pas généralement pas trop impactés par les changement du noyau. L'interface entre le noyau et les drivers est bien définie et ne devrait pas changer tous les jours.
@Uther petite question sur quelque chose que je n'ai pas bien compris:
- pas mal de gens disent que Rust n'a pas d'ABI stable, ce qui est très handicapant si l'on se retrouve à devoir passer par l'ABI C pour faire des bibliothèques partagées
- cependant, ' extern "Rust" ' fait bien parti de la doc et aucune mention de potentiel problème avec elle, ni de limitation avec la création de .dll/.so
Du coup, les bibliothèques partagées en Rust, ça donne quoi ?
En effet l'ABI "Rust" de base n'est pas stable, ce qui fait qu'on évite le plus souvent les bibliothèques partagées au format Rust car elles ne sont compatibles qu'avec les programmes compilées avec la même version du compilateur. C'est pour cela que le compilateur Rust lie statiquement par défaut.
Si on veut une DLL qui puisse s'interfacer avec d'autre langages, on peut forcer l'utilisation de l'ABI du C qui est stable, via extern "C" pour les fonctions et #[repr(C)] pour les types. L'inconvénient est que forcément on perd les possibilités offertes par le typage Rust qui n'ont pas d'équivalent en C.
extern "Rust" n'est malheureusement pas une solution. Ça indique juste explicitement d'utiliser l'API Rust instable, ce qui revient à la mème chose que ne pas utiliser extern du tout.
Si jamais tu as absolument besoin de DLL qui marchent quelque soit la version du compilateur, il faut malheureusement pour le moment te restreindre à l'API C. Je sais qu'il y a des crates comme stable_api et stabby qui essaient d’émuler une API Rust stable au travers de l'ABI C, mais je ne les ai pas utilisée, je ne sais pas ce que ça vaut.
c'est surtout que dans l'écosytème des distrib ou de gros projet divisé en sous produit, on distribue des bibliothèques partager pour ne pas recompiler la moitié des libs pour une correction mineure.
C'est donc une contrainte à garder à l'esprit et qui demande réflexion
- soit accepter de partir sur une version LTS et y rester à moins qu'un changement significatif en vaille le coup. C'est en vrai un choix qui s'entend pour un projet avec une porter réduite, j'ai vu des appli encore utiliser GCC 4.8 ou 4.9 de mémoire, alors que la versions 9 était disponible de moins presque 1 an et proposait les sanitizer (bon dieu, ce que leur aide me manque sous windows). Mais un compilateur introduit rarement de faille et le changer en cours de risque, c'est prendre des risques de régression (ou de se rendre compte que du code marchait parce que le compilo avaient un comportement non standard)
- soit accepter de tirer les dépendances nécessaire et de les lier statiquement à chaque appli. De nos jour, on a beaucoup de RAM et d'espace de stockage, l'économie que ça permettra ne vaut certainement pas le coup et ça n'est pas ingérable sur un projet privé.
- soit ne passer que par de l'ABI C pour contourner l'ABI Rust, mais cela complexifie l'usage
C'est pas mal rebutant pour motiver le passage de libs en Rust
C'est pas vraiment ce qui est encouragé par l'écosystème Rust qui n'a pas de version LTS et sort une nouvelle version toutes les 6 semaines. La rétrocompatibilité étant plutôt bien assurée, et la montée de version étant facile via l'outil standard d'installation du compilateur (rustup), on a tendance à changer facilement pour la version la plus récente du compilateur.
C'est en effet la façon standard de faire en Rust. L'outil standard de build et gestion de dépendances (cargo), fourni de base avec le compilateur, rend ce mode de fonctionnement très simple et efficace.
Il tire les dépendances depuis le dépôt central "crates.io" (ou éventuellement un dépôt git spécifique), les recompile automatiquement et les lie statiquement.
En général on ne fait ça que si on veut que si on veut que la bibliothèque soit utilisable dans d'autres langages ou si on veut mettre en place un système de plugin. Dans ce cas là on a pas le choix, l'ABI C étant l'interface commune utilisée par quasiment tout les langages pour permettre d'interagir entre eux.
Non, le "C" permet de tout faire, y compris les couches que rajouteraient les langages de plus haut niveau pour sécuriser la mémoire.
La sécurisation de la mémoire dépend essentiellement du programmeur et des outils qu'il a mis en place. Avoir des fonctions d’allocations sécurisé est très facile à faire. Faire du bound checking , de la détection de mémory leaks ou d’overwrite en temps réel est aussi très simple à mettre en œuvre en ‘C’.
Développer des langages pour intégrer une partie du travail (sécurisation) ou de l’organisation (++) du développeur est une perte de temps monumental pour l’informatique au sens large.
Enfin, Il faut savoir reconnaitre les "butter soft". le "C", seul langage élaboré par un ingénieur est un "butter product" . On ne met pas à jour le beurre, on ne le remplace pas, on ne l'améliore pas.
Pour des systèmes de plugins, je vois un peu de WASM.
Permettre de tout faire, ne veut pas dire que c'est l'outil idéal pour tout faire. Si tu veux rajouter assez de couches au C pour le sécuriser aussi bien que Rust, tu vas juste créer un nouveau langage.
C'est d'ailleurs plus ou moins comme ça qu'est né Rust, quand Mozilla s'est rendu compte que sécuriser complètement le C++ introduisait tellement de limitations et d'incompatibilités avec l'existant qu'un nouveau langage était plus logique, il se sont intéressé au projet personnel d'un de leur employés.
C'est tellement simple que, même dans les OS, les bases de données et les navigateurs dont la sécurité est particulièrement surveillée, plus des deux tiers des vulnérabilités sont causées par des erreurs mémoires.
C'est en effet une perte de temps quand on a sa disposition une armée de développeurs de génie, parfaitement formés et surtout qui ne font jamais la moindre erreur.
Mais dans le monde réel, ça ne marche pas..
C’est un peu ce que l’on reproche au C. Il fait reporter une charge au programmeur qui pourrait être automatisée et rendue plus fiable. Oui, C permet de comparer un indice et une taille de tableau… donc permet le bound checking mais on n’est pas à l’abris d’un oubli. Il n’y a pas d’annotation ou «*pragma*» permettant de rendre le bound checking implicite en tapant a[i]=2.
Tu penses à quel outil ? Lint, SonarQube, … pas sûr que cela détecte autant qu’un compilateur associé à un langage intégrant la sécurité.
En poussant l’argument, on pourrait se contenter de programmer en langage machine (même pas en langage assembleur). L’évolution des langage a justement pour but d’intégrer une partie du travail du programmeur.Développer des langages pour intégrer une partie du travail (sécurisation) ou de l’organisation (++) du développeur est une perte de temps monumental pour l’informatique au sens large.
En effet WASM est une technologie intéressante pour un système de plugin vu que ça apporte aussi le sandboxing. Par contre, c'est plus complexe a mettre en œuvre qu'un simple chargement de bibliothèque dynamique, ça a un impact sur les performances et on va aussi avoir des limitations au niveau de l'API.
« Les développeurs Linux sont des mégalomanes pédants et condescendants », d’après le créateur de redox_os
« 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
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.
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.
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é.
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.
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++.
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.
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. »
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. »
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.
Et vous ?
Quels sont les avantages et les inconvénients de Rust par rapport au C pour le code du noyau ?
Voir aussi :
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
Pour faire une bonne vinaigrette.Remonté contre les habitués du C qui freinent les mises à jour de la base de code du noyau vers Rust
Il faut de l’huile et du vinaigre !!!!
A mon point de vue, ce n’est qu’une question de temps et de génération.
Ma génération, qui a étais élevé au bon code en C et C++, vers la fin du siècle dernier (1992).
Les jeunes et futures générations qui intégrerons et compileront plus facilement le code en Rust.
Moi, quand j’ai commencé à développer, le Java Scripte n’existais pas.
Aujourd’hui, tous les jeunes savent coder en Java Scripte.
Haaa !!!
Il ne faut pas oublier, non plus, que le créateur de PHP a conçu ce langage en C, parce que il en avait marre de répéter les mêmes routines en C, pour construire des pages Internet , a l’époque.
C’est une question de temps, uniquement !!!
Ne pas savoir n’est pas une faute si l’on cherche à combler ses lacunes.
"Il n'y a pas d'obstacles infranchissables , il y a des volontés plus ou moins énergiques voilà tous" Jules Vernes
Cette "mégalomanie" existe dans toutes les équipes qui sont formattés à travailler avec un langage informatique. Vous allez dans les banques où on fait du COBOL, les développeurs rabaisseront ceux qui font du Java pour sa syntaxe, ceux qui font du Java rabaisseront ceux qui font du NodeJS/TypeScript pour son manque de typage runtime, ceux qui font du NodeJS/TypeScript rabaisseront ceux qui font du Python pour ses performances, et généralement tout le monde excepté ceux qui font du PHP rabaisseront PHP
Il faut aller au-delà de cela, de cette passion qui nous anime pour un langage informatique, parce que oui nous avons appris, travaillé et en quelque sorte "grandi" avec un certain langage, et on arrive d'ailleurs à reconnaitre les générations grâce à leur formation universitaire Pascal, C++, Java, et plus récemment Python... Et je comprends aussi que certains en ait marre d'apprendre le dernier langage à la mode (je pense personnellement aux langages JVM tels que Scala complètement mort et Kotlin propulsé par IntelliJ+Google suite au procès d'Oracle en ayant fait du Java), ce qui me perturbe c'est que Rust soit considéré comme une mode ou bien les goûts syntaxiques évoqués par certains pour ne pas adopter le Rust. Rust est basé sur le retour d'expérience des langages existants, il existe des raisons pour laquelle Rust inclu/limite des features, comme pourquoi il n'y a pas d'héritage à plusieurs niveaux, pourquoi on continue à utiliser le point-virgule etc (je ne vais pas rentrer dans les détails ici)
Un langage informatique est un outil, ce n'est pas votre enfant ou votre animal de compagnie, l'affect n'a pas lieu d'être. Il faut citer les "vrais" avantages et inconvénients techniques de Rust pour être juste, Rust n'est pas parfait : moins de libraries contrairement à Go qui est supporté par Google (quelqu'un sait s'il existe un driver Sybase en Rust ?), lent à compiler etc... mais en tant qu'expert seriez-vous capable de me citer des langages libres (compilateur inclu) qui sont à la fois memory-safe, null-safe, thread-safe et qui ne requirent pas une VM que l'on doit installer et qui doit gérer un système de ramasse-miettes ?
Bref, pour en revenir à Linux, bien que le C soit un langage simple et très apprécié, ce dernier ne respecte pas les critères cités au-dessus (je vous invite à regarder les taux des failles de sécurités causés par l'absence du memory-safe ou null-safe), donc qui maintiendra aussi bien le noyau lorsque Linus Torvalds ne sera plus de ce monde ?
N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java
Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ?
Je dirais même: Cette "mégalomanie" existe dans toutes les équipes qui sont formatées à travailler avec un seul langage informatique.
Je ne suis que partiellement d'accord. Je pense personnellement qu'il y a une forme d'art à concevoir et écrire du code. Il y a tout simplement quelque chose de plaisant et d'harmonieux à voir les patterns se former, les couches communiquer. Il y a de la beauté dans certaines expressions épurées.
Et dès le moment où ce n'est plus seulement un outil ou un travail alimentaire, alors les goûts de tous entrent en considération, un peu comme pour la musique et pour tant d'autres sujet ou soudain tout le monde a un avis extrêmement tranché sur ce qui est bien et ce qui ne l'est pas.
J'aime bien la syntaxe de Rust, mais ça doit venir du fait que j'ai pratiqué plusieurs langages assez différents au lieu de me spécialiser dans un seul, et du coup, mes goûts personnels ont évolué avec chaque langage et la philosophie qu'il portait.
J'essaye toujours de choisir mes outils en fonction des avantages qu'ils vont me procurer, mais il y aura toujours certains outils qui me plairont plus que d'autres pour une question de goûts personnels, sur un périmètre donné.
Bien entendu, quand on collabore sur un projet, il faut être capable de faire des compromis, comme sur le style par exemple, pour garder une base de code maintenable et compréhensible.
Je pense que le gros souci, là, c'est qu'il y a deux langages avec une philosophie différente, et sur deux périmètres différents: un est à l'origine de l'ensemble du noyau, l'autre n'est utilisé que pour certains modules (souvent nouveaux), et c'est peut-être vu par certains développeurs comme du code de seconde zone - d'où le manque d'effort et d'engouement de leur part.
Et le gars de redox_os fait un peu le malin dans son tweet et en profite pour se faire de la pub, mais je suis certain que si demain, ses nouveaux modules étaient développés en Lua (pour gagner du temps sur la compilation, puisque tu as évoqué le temps de compilation de Rust) avec le reste en Rust, il y aurait la même animosité de la part d'une partie de ses développeurs, et peut-être une forme de mépris.
Désolé pour le pavé, mais ta réponse m'a inspiré!
Copier c'est copier; voler c'est vendre un CD une vingtaine d'euros!
Code C : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
Si c'est probablement vrai ce n'est pas pour autant une bonne idée que de s'enfermer dans ce que l'on sait déjà.
A l'école, j'ai appris le COBOL et j'avais une spécialisation "télématique".
Je ne suis même pas certain que tout le monde comprennent ce dernier mot aujourd'hui (pour info : le Minitel).
Heureusement que je n'en suis pas resté à cela.
Cela ne m'empêche donc pas d'aujourd'hui de faire du C# après être passé par Turbo Pascal, C, C++, Visual Basic, Delphi, Javascript entre autres.
L'informatique bouge sans cesse. Un développeur qui resterais immobile va mourir ou se retrouver enfermé dans des techno obsolètes.
J'ai à un moment complètement raté les techno liées au Web. J'ai fait de gros effort pour rattraper mon retard et sortir du client lourd en complète perte de vitesse.
J'ai rencontré un développeur Cobol a qui son patron refusait toute formation, parce qu'il voulait le garder sous la main.
Alors certes, on ne peut pas tout apprendre, mais rester sur ses acquis n'est pas une bonne idée non plus.
--
vanquish
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager