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 :
Le problème dans ce que tu dis, c'est la défintion de ton "on", c'est qui au juste "on" ? Parce que sauf erreur de ma part, il n'y a jamais eu Linus Torvald dans ce "on", et je pense qu'il y a aussi un certain nombre de gens qui sont très spécialisés dans le développement du noyau Linux qui ne faisait pas parti de ce "on" mais fait parti de celui pour le Rust.Envoyé par Neckara
Merci pour l'article, très intéressant. Je trouve que c'est une bonne idée d'introduire un nouveau langage sur le développement Linux, cela permettra a des personnes qui sont effectivement intéressées par la programmation linux et système de clairement marquer leur intérêt pour ce champ de la discipline.
Je serais heureux de voir les entreprises adopter plus largement des solutions linux, pour l'instant d'après mon expérience beaucoup utilisent encore des solutions IBM Legacy (z/OS, AIX). Peut-être des solutions IBM plus récentes comme Red Hat trouveront-elles bientôt un intérêt auprès de nos entreprises européennes? Ou plus généralement les systèmes Linux + Support, pourquoi pas avec Ubuntu et Canonical? Cela aiderait aussi a former de futurs mainteneurs linux francophones (synergie entre une activité professionnelle et un centre d'intérêt personnel).
ouais, enfin y'a pas que Linus Torvald dans le monde...
Google poussait le Go... Google c'est pas n'importe qui non plus.
M$ poussait le C#.
Android (encore Google), le Java et Kotlin.
Apple, l'Objective C, maintenant c'est le Swift si je ne dis pas de bêtises.
Et je dois en oublier. Aucun de ceux que j'ai cité ne sont n'importe qui. Alors Linus nous dit blanc, M$ nous dit noir, Apple, nous dit vert, et Google nous dis rouge rayé de bleu.
Tout le monde nous dit une chose différente, comment veut-on qu'on s'y retrouve ensuite si tout le monde a au final son propre langage ?
D'un côté :
-- personne ne s'amuse vraiment à changer de langage tous les trois ans ;
D'un autre côté :
-- pourquoi avoir besoin qu'un langage soit utilisé par tous pour s'y mettre soi-même.
Je croyais qu'il fallait être "ouvert" et choisir un langage "parce qu'il est le plus adapté pour un projet" et non parce que "on est ouvert, la preuve, on code tous dans le même langage".
Non.
D n'a jamais marché et ne marchera pas pour différentes raisons. Déjà il a souffert en interne des différentes implémentations de la bibliothèque standard ce qui l'a largement decrédibilisé. Ensuite il possède un garbage collector, personne ne souhaite ça dans un noyau de système d'exploitation. Et pour finir c'est un langage qui n'a rien apporté de nouveau.
Go et Rust ont commencé à peu près à la même période. Pourtant Rust fonctionne.
Go est langage qui selon moi ne décollera jamais car il est trop focalisé sur un principe de « C haut niveau ». Il n'apporte rien de nouveau, il a un garbage collector, il n'a pas de généricité, il supporte les pointeurs void et sa gestion des erreurs est mal faite.
Rust n'a aucun de ces défauts il apporte beaucoup de choses propres et nouvelles donc je pense qu'il n'a pas de soucis à se faire.
Soyons sérieux, à part les bibliothèques qui ne sont pas liées intrinsèquement au langage, il n'y a pas non plus 50 besoins de projets différents qui nécessitent 50 langages différents, et qui sont en soit très similaires sur bien des aspects.
Ce n'est pas une question qu'un langage soit utilisés par tous, mais d'éviter une fragmentation inutile sous l'impulsions d'effets de modes.
Je te rappel que le sujet de l'article c'est "Rust au sein du noyau Linux". Je ne pense pas que Microsoft ai poussé pour faire du C# dans le noyau Linux.
Google poussait le Go... Google c'est pas n'importe qui non plus.
M$ poussait le C#.
Android (encore Google), le Java et Kotlin.
Apple, l'Objective C, maintenant c'est le Swift si je ne dis pas de bêtises.
Et je dois en oublier. Aucun de ceux que j'ai cité ne sont n'importe qui. Alors Linus nous dit blanc, M$ nous dit noir, Apple, nous dit vert, et Google nous dis rouge rayé de bleu.
Tout le monde nous dit une chose différente, comment veut-on qu'on s'y retrouve ensuite si tout le monde a au final son propre langage ?
En outre j'ai bien pris la peine de mentionner qu'il y d'autres personnes qui gravitent autour du développement du noyau Linux que Linus Torvald qui partagent cet enthousiasme.
C'est aussi la preuve que notre secteur manque encore de maturité.Ce n'est pas une question qu'un langage soit utilisés par tous, mais d'éviter une fragmentation inutile sous l'impulsions d'effets de modes.
Si pour toi "on" c'est les sociétés derrière chaque langage, évidement qu'il vont te préférer leur propre solution mais bon c'est pas ce que j’appellerais une référence.
Google poussait le Go... Google c'est pas n'importe qui non plus.
M$ poussait le C#.
Android (encore Google), le Java et Kotlin.
Apple, l'Objective C, maintenant c'est le Swift si je ne dis pas de bêtises.
De plus il faut comparer ce qui est comparable. Les langages que tu cites ne sont pas dans la même catégorie que Rust. Ils sont tous difficilement utilisable pour de la programmation système. Les concurrents de Rust seraient plutôt a chercher du coté de Zig ou Nim.
Heu, Go est loin d'être un langage délaissé. Il est même largement devant Rust dans le classement tiobe (même si ça ne veut pas dire grand chose).
Donc je re-pose la question : quelles "nouvelles choses" ?
Perso, je trouve que Rust a beaucoup d'avantages mais je trouve dommage que certains de ses fanboys le promeuvent en démontant les autres langages, souvent abusivement en plus.
D'accord avec toi. Pour moi l'aspect "Marketing" de Rust, même si c'était le seul avantage de ce nouveau langage par rapport au C, ce serait déjà très bien, si cela encourage la jeune génération a s'intéresser à la programmation système.
Le problème c'est que si tu fais du Rust dans Linux, du C# dans Windows, du Swift dans Apple, du Kotlin dans Android, du JS dans les navigateurs, du C++ en embarqué, etc. etc. tu as une fragmentation des langages non par par réels besoins, mais par plateformes.
Donc derrière, dès que tu veux faire du multi-platerforme, ou passer de l'une à l'autre, ça devient vite enquiquinant.
Et ça, c'est juste pour les OS, derrière t'as du Python/R pour des gros calculs, t'as du Fortran dans les applications bancaires (), t'as du machin et du bidule à gauche et à droite.
Rien qu'en développement Web, passer du JS au PHP c'était enquiquinant. Parce qu'ils avaient leurs petites différences, et qu'on n'arrivait jamais à se rappeler lequel fait comme ça, et lequel fait comme ci. Maintenant au moins en full JS on n'a plus ce problème, et ça permet de transférer facilement des bouts de codes du client au serveur et inversement. Même si JS est loin d'être un bon langage malheureusement.
Le problème, c'est qu'on se retrouve à travailler sur des projets "ah bah moi j'utilise du C#, ah bah moi j'utilise du Java, ah bah moi j'utilise Matlab (".
Bon, ok, pour les deux derniers j'exagère. Donc pour mon domaine, on peut déjà se retrouver avec des bouts de codes dans 7 langages différents,et je pense que j'en ai encore oublié quelques uns. Le plaisir de jongler ainsi... ><
Go fonctionne très bien, même mieux que Rust en terme d'adoption générale. Mais bien que l'on cite souvent ces deux langages ensemble, ils ont pourtant des visées très différentes. Je pense que le malentendu vient du fait que à la sortie de Go, Google l'a présenté à tort comme un langage système, et qu'a l'époque Rust commençait à faire un peu parler de lui même s'il n'est sorti officiellement que 3 ans plus tard. Google est revenu sur la qualification de langage système pour Go, mais l'idée que c'était 2 langages similaire sortis en même temps est restée.
En fait Go est au C ce que Java a été au C++ : une bonne simplification quitte a abandonner le coté système. Il en résulte un langage très simple a apprendre et relativement efficace. Il remplit parfaitement son rôle dans les domaines ou Java fonctionne bien et il y a été relativement bien adopté.
S'il fallait caser le Rust quelque part, ça serait plutôt du coté du C++, car tout comme lui il a l'intention d’apporter la capacité de faire des abstractions de haut niveau sans renoncer à la programmation système. Il a cependant fait des choix différents dans certains de ses mécanismes, ce qui lui permet notamment de garantir la sécurité mémoire.
Rust c'est bon mangez-en
Ok, Rust est un successeur valable de C. Si Linus Torvalds le dit, vu l'impact ENORME de Linux sur l'ensemble de l'IT, on peut l'écouter. Perso, je développe pour des microcôntrolleurs 8 bits, c'est du loisir, donc ASM Microchip et 8082, et langage C. Je n'ai même pas de compilateur C++ pour mes petits projets. Je ne suis pas près de faire du Rust...
J'utiliserai bien Rust pour faire du WebAssembly.
Le problème c'est que si tu fais du Rust dans Linux, du C# dans Windows, du Swift dans Apple, du Kotlin dans Android, du JS dans les navigateurs, du C++ en embarqué, etc. etc. tu as une fragmentation des langages non par par réels besoins, mais par plateformes.
Donc derrière, dès que tu veux faire du multi-platerforme, ou passer de l'une à l'autre, ça devient vite enquiquinant.
Et ça, c'est juste pour les OS, derrière t'as du Python/R pour des gros calculs, t'as du Fortran dans les applications bancaires (
Rien qu'en développement Web, passer du JS au PHP c'était enquiquinant. Parce qu'ils avaient leurs petites différences, et qu'on n'arrivait jamais à se rappeler lequel fait comme ça, et lequel fait comme ci. Maintenant au moins en full JS on n'a plus ce problème, et ça permet de transférer facilement des bouts de codes du client au serveur et inversement. Même si JS est loin d'être un bon langage malheureusement.
Le problème, c'est qu'on se retrouve à travailler sur des projets "ah bah moi j'utilise du C#, ah bah moi j'utilise du Java, ah bah moi j'utilise Matlab (
Bon, ok, pour les deux derniers j'exagère. Donc pour mon domaine, on peut déjà se retrouver avec des bouts de codes dans 7 langages différents,et je pense que j'en ai encore oublié quelques uns. Le plaisir de jongler ainsi... ><
Tu mélanges tout et c'est usant de te voir dire la même chose en boucle. Déjà des secteurs d'activités ont des besoins différents. Par exemple si tu fais implémentes des drivers audio tu as besoin de générer du code très performant et déterministe au niveau des accès mémoire. Cette contrainte rend l'utilisation de langage haut-niveau garbage collecté impossible. A contrario, si tu fais du développement web coté client il te faut un langage qui va s’exécuter dans un environnement sandboxé pour des raisons de sécurité.Il te faudra donc faire du Js ou du WASM (ou utilisé un langage qui compile vers l'un des 2). Et ce n'est que 2 exemples, suivant les secteurs tu peux trouver plein de raisons de plutôt utiliser X ou Y. Bref, contextes différents = contraintes différents = besoin de langages différents. Ensuite, avoir plein de langages est une bonne chose. L'informatique n'est pas une science assez vielle pour croire que les langages que l'on a aujourd'hui sont ce qui se fait de mieux. Autrement, on aurait pu garder que le Cobol depuis le début si on suit la logique inverse. Donc, il est important de tester des choses (ie, inventer de nouveaux langages) et de faire jouer la concurrence pour garder les meilleurs via de la sélection "naturelle".
Que ce soit clair, je suis bien d'accord avec la remarque de fond, jongler avec beaucoup de langages dans un même projet c'est usant, cependant je pense qu'elle c'est hors-sujet avec l'article, car dans ton genre d'exemple, la variété des langages n'est pas souvent justifiés. Ici on parle bien d'ajouter un langages parce que des gens ont consciencieusement réfléchi et estimes que ce serait bénéfique.
Le problème c'est que si tu fais du Rust dans Linux, du C# dans Windows, du Swift dans Apple, du Kotlin dans Android, du JS dans les navigateurs, du C++ en embarqué, etc. etc. tu as une fragmentation des langages non par par réels besoins, mais par plateformes.
Donc derrière, dès que tu veux faire du multi-platerforme, ou passer de l'une à l'autre, ça devient vite enquiquinant.
Et ça, c'est juste pour les OS, derrière t'as du Python/R pour des gros calculs, t'as du Fortran dans les applications bancaires (
Rien qu'en développement Web, passer du JS au PHP c'était enquiquinant. Parce qu'ils avaient leurs petites différences, et qu'on n'arrivait jamais à se rappeler lequel fait comme ça, et lequel fait comme ci. Maintenant au moins en full JS on n'a plus ce problème, et ça permet de transférer facilement des bouts de codes du client au serveur et inversement. Même si JS est loin d'être un bon langage malheureusement.
Le problème, c'est qu'on se retrouve à travailler sur des projets "ah bah moi j'utilise du C#, ah bah moi j'utilise du Java, ah bah moi j'utilise Matlab (
Bon, ok, pour les deux derniers j'exagère. Donc pour mon domaine, on peut déjà se retrouver avec des bouts de codes dans 7 langages différents,et je pense que j'en ai encore oublié quelques uns. Le plaisir de jongler ainsi... ><
De plus si tu te retrouves à jongler entre 7 langages différents il y a des chances que ce soit par manques d'efforts pour harmoniser un peu tout cela, c'est un problème organisationnel. Avoir plusieurs langages, pourquoi pas mais dans ce cas il faut bien borner ce qu'on fait avec chacun d'entre eux et éviter ceux qui font la même choses.
Bon je dis ça mais je suis en Java, avec du Web de temps en temps
Ça l'air rigolo! WebAssembly je connaissais pas mais ça a l'air ambitieux comme projet... il faudra que je regarde si il y a des projets open-source intéressants en cours avec cette techno.
Et c'est usant de vous voir répondre ces bêtises... me forçant à repréciser mes propos...
Tu vas me dire quels sont les besoins tellement différents entre e.g. un IPhone, un Androïd, et un Window Phone ? Tu vas me dire en quoi ce sont des "secteurs d'activités" tellement différents ?
Cela n'est donc pas un argument pour dire qu'il faut des langages différents pour des besoins différents, mais que les langages où on ne peut pas désactiver le garbage collecteur ne sont pas top...
Et bien évidemment, tu nous fais un réponse complètement à côté de la plaque. Le fait qu'il faille faire du JS n'est pas intrinsèque au langage, mais un choix arbitraire qui a été fait. Si demain on décidait d'utiliser un autre langage, ben ça sera cet autre langage qu'on utilisera.
Le WASM, peut être considéré comme un langage assembleur. Et pour des langages qui compilent vers le WASM... t'as LLVM et emscripten, t'en as une petite floppée. Sachant que là encore, ce n'est pas lié aux qualité du langage intrasèque, mais à des choix arbitraires qui ont fait qu'on a ajouté un langage donné à emscripten. Donc si demain un nouveau langage devient très bon... il est facile à parier qu'il sera ajouté à emscripten.
Donc encore un fois, cela n'est donc pas un argument pour dire qu'il faut des langages différents pour des besoins différents...
Ben... loupé... comme on l'a vu, la plupart de tes contextes ne justifient pas d'utiliser des langages différents...
Derrière bien évidemment on rajoute HTML/CSS3, LaTeX, et SQL. Donc bien au moins 10 langages. Et tout en passant sans cesse de l'un à l'autre en fonction des besoins ><.
C'est comme l'Anglais, c'est peut-être pas une langue parfaite, mais je suis bien content que pratiquement tout le monde la parle... Parce que si je devais apprendre une langue différentes avant chaque conférences... je te dis pas le bordel.
Le mieux est l'ennemi du bien. On s'en fout d'avoir l'optimal, le tout est d'avoir quelque chose de bien.
Non, ça c'est une bêtise. Déjà un langage évolue et peut lui-même tester des choses.
Ensuite, il y a une différence entre tester une nouvelle chose, et utiliser cette nouvelle chose en production.
Car si la première peut se faire en se greffant sur un langage existant et attendre son implémentation dans le langage, le second conduit à une fragmentation non-productive.
Parce qu'il ne faut pas oublier que le but n'est pas d'atteindre le meilleurs langage, mais d'écrire des logiciels. De plus les processus de sélection "naturelle" ne conduire pas à la sélection du "meilleur" langage, c'est une mécompréhension des mécanismes de l'Évolution.
Par exemple pour RUST, je trouve qu'il a fait une grosse bêtise en essayant de se démarquer ainsi des autres langages. Il aurait mieux fait soit de reprendre le formatage du C++ avec parenthèses/accolades, soit du Python avec juste des indentations, mais pas faire un mix choquant des deux.
Il reprends le concept de macro qui ont été abandonnés en C++... Il aurait mieux faire de reprendre les fonctions inlines/constexpr, ainsi que d'avoir une prise en charge des variadics comme arguments de fonctions.
Le format des chaînes de caractère est bizarre, ils auraient mieux fait de reprendre celle du JS.
Bref, pour un nouveau langage issue de l'évolution, j'ai déjà quelques critiques à faire, sans même l'avoir encore touché en profondeur. Donc demain un nouveau langage Rust++ pourra apparaître corrigeant cela.
Sauf que c'est bien beau de voir l'évolution des langages... mais derrière faut aussi se rappeler qu'il faut coder avec...
Oui, et on peut dire cela de presque tout nouveau langage qui sort.
Il ont peut être réfléchi, mais ça continue de conduire à une fragmentation, sans que forcément beaucoup de personnes suivent... Si ce langage est très bon, le problème est la multitude de langage moins bon qui ont été proposé depuis. Je veux dire que s'il avait été le seul successeur du C++, il serait peut-être aujourd'hui bien plus largement adopté.
Tant qu'il n'y aura pas de consensus au niveau mondial parmi l'ensemble de la recherche, c'est pas prêt de se régler...
Dans le playground de Rust, ça fonctionne.
Code : Sélectionner tout - Visualiser dans une fenêtre à part fn main() { println!("Hello, world!"); }
Je ne vois pas bien le mix avec Python du coup.
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