Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

L'année 2020 est-elle celle de Rust au sein du noyau Linux ? C'est ce que suggère une sortie de Linus Torvalds
Qui donne des instructions sur l'introduction de son support au système de build

Le , par Patrick Ruiz

165PARTAGES

19  0 
Les principaux mainteneurs du noyau Linux ont un âge qui commence par le chiffre 5. Certains se rapprochent même de la soixantaine. Du coup, la communauté du célèbre noyau open source commence à penser au changement de générations. Une nouvelle dont la tranche d’âge se situe dans la trentaine gravit les échelons, mais comme Linus lui-même le souligne : « Il s'avère qu'il est vraiment difficile de trouver des personnes qui sont des mainteneurs » ; un fait lié à ceci que le développement du kernel Linux continue de se faire en C et assembleur – des langages auxquels la vieille génération est plus accoutumée ? C’est une possibilité et elle est susceptible d’expliquer pourquoi 2020 pourrait être l’année du langage Rust au sein du noyau Linux.

En effet, au troisième trimestre de l’année précédente, on parlait déjà de la possible entrée au sein du noyau Linux d’un framework pour la mise sur pied de pilotes en langage de programmation Rust. En 2020, la communauté Linux est désormais lancée sur des réflexions en lien à la façon d’intégrer la prise en charge du langage de Mozilla Research au système de build. « Nous devons adopter une approche de prise en charge identique à celle des compilateurs et procéder à la vérification de la disponibilité de divers drapeau de compilation à l’étape de configuration », a précisé Linus. La sortie du créateur du célèbre noyau open source marque en principe son accord avec le principe de la prise en charge de plus en plus importante du langage Rust au sein de Linux. Sur la base de ce seul élément, 2020 pourrait déjà bien être considéré comme l’année du langage Rust au sein du noyau Linux. En effet, ce dernier a, semble-t-il, réussi à convaincre Linus Torvalds là où C++ a échoué.


Le fait avec 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 est qu’il a obtenu la reconnaissance de « plus aimé » des développeurs habitués de la plateforme de questions-réponses sur des sujets liés à l’informatique – StackOverflow. Au terme de l’édition 2019 de son enquête qui a mobilisé près de 90 000 travailleurs de la filière programmation informatique, le langage a concentré 83,5 % de retours positifs. Ce sont donc près de 75 000 développeurs de ce sondage Stack Overflow qui ont fait savoir qu’ils utilisent le langage Rust et qu’ils vont continuer à en faire usage ; autrement dit, des développeurs qui, après quelques expériences avec le langage, en sont tombés amoureux. C’est une autre enquête cette fois menée par l’équipe de développement du langage et parue au premier trimestre de l’année en cours qui est venue mettre en lumière le fait que le langage reste encore principalement utilisé pour des projets personnels. Raison majeure : manque d’adoption par les entreprises.

Après, la donne est en train de changer puisque le langage commence à bénéficier de soutiens d’acteurs de l’industrie informatique et pas des moindres. À date, il existe une projection du langage Rust pour les API Windows Runtime. C’est une annonce de Microsoft parue au mois de mai dernier. Rust rejoint ainsi C++ avec la bibliothèque Rust/WinRT, ce qui ouvre la possibilité aux développeurs Rust les portes de la mise sur pied de composants et pilotes pour Windows.

C’est un grief qui revient à 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 un défi à relever pour le futur en matière de programmation système et d’après Microsoft, Rust est la meilleure chance de l’industrie informatique pour la mise sur pied d’applications système sécurisées. Ce sont très certainement des développements que la communauté Linux prend en compte au moment de la prise en charge sans cesse revue à la hausse de la prise en charge du langage Rust au sein du noyau Linux. Lorsque l’actuelle équipe de mainteneurs faite de quinquagénaires sera considérée comme les programmeurs COBOL des années 2030, celle des trentenaires sera aux affaires occupée à manipuler un langage sur lequel les experts s’accordent sur ceci qu’il offre de meilleurs gages de sécurité.

Source : lkml

Et vous ?

La difficulté de trouver des mainteneurs est-elle la conséquence de ce que le développement du noyau Linux continue de se faire en C et en assembleur au moment où les développeurs s’intéressent de plus en plus à des langages comme Rust ?
Êtes-vous aussi d’avis que la communauté Linux anticipe non seulement sur les départs en retraite des actuels mainteneurs et sur les qualités que Rust offre en comparaison au langage C ?

Voir aussi :

Rust s'approche de sa première version stable, Mozilla publie une nouvelle préversion de son langage dérivé de C/C++
Linux : un framework pour la mise au point de drivers en langage Rust pourrait faire son entrée dans le noyau de l'OS
L'équipe de npm choisit Rust pour gérer les goulots d'étranglement liés au CPU au détriment de Go, C, C++ et Java, voici les raisons de ce choix

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 20/07/2020 à 13:07
Citation Envoyé par Neckara Voir le message
Oui, mais le problème, c'est qu'il y a 2-3 ans, on nous disait de faire du Go, il y a 5-6 ans fallait faire du D. Et dans 2-3 ans on nous dira d'utiliser un autre langage.
Quand tu choisis un langage pour un projet, c'est une décision qui t'engage sur des décennies, tu ne peux pas le réécrire complètement dans un autre langage tous les 2-3 ans.
Si tu choisis tes langages en fonction des trending topics des réseaux sociaux peut-être. Je crois pas que grand monde qui fasse de la vraie programmation système ait sérieusement envisagé Go ou D. Si on prend la peine de se renseigner un minimum sur ces langages, on voit vite qu'ils sont quasi inutilisable sans GC.

Et quitte à ressembler à un disque rayé, on ne demande pas de réécrire l'intégralité du code existant en Rust. Le but est justement de permettre au code Rust de s’intégrer naturellement au code C existant dans le noyau. Ça devrait être utile avant tout pour faire des modules séparés, pas pour refondre le noyau en entier.

Citation Envoyé par SimonDecoline Voir le message
C'est quoi "le C++" ? C++98, C++11, C++20 ? Le C++ d'aujourd'hui a également beaucoup de fonctionnalités "sécurisantes". Rust est certes très efficace à ce niveau mais il faut comparer ce qui est comparable.
Les fonctionnalités "sécurisantes" de C++ sont quand même limitées. Elle ne protègent pas totalement des erreur mémoire, mais surtout, c'est une surcouche à déposer soi-même sur une base non sécurisée. Si on ne la déploie pas bien comme il faut, on peut passer à travers sans s'en rendre compte.
Alors qu'en Rust c'est l'inverse, tout est sécurisé par défaut et si tu veux passer a travers la couche de sécurité il faut le faire explicitement.

Citation Envoyé par SimonDecoline Voir le message
Encore une fois, ce n'est pas nouveau : les smart pointers de C++ existent depuis C++11, soit 9 ans. Aujourd'hui, la norme par défaut des compilateurs, c'est C++14 voire C++17.
Les smart pointers et les divers mécanismes introduits dans les versions modernes de C++, ne suffisent pas à garantir la sécurité mémoire, même si c'est mieux qu'avant. Le C++ de part son historique ne peut techniquement pas offrir le même genre de garantie que Rust sur la mémoire.

Citation Envoyé par Neckara Voir le message
À quand un unique langage pour les gouverner tous, pour les trouver, pour les amener tous, et dans les ténèbres les lier ?
Probablement jamais et c'est tant mieux, les avantages de certains langage dans certains contextes sont des inconvénients dans d'autres. Il y a des choses que je ne ferais pas en Javascript, tout comme il y a des chose que je ne ferais pas en Rust (et il n'y a rien que ne ferais en PHP sauf sous la contrainte d'une arme ).
13  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 20/07/2020 à 1:06
Citation Envoyé par Neckara Voir le message
Il y a quand même des choses qui me choquent quand je lis du code écrit en Rust, comme le manque de parenthèses pour les if. Hérésie !
Si c'est ce qui te choques le plus quand tu lis du Rust, je dirais que ça va. Il y a quand même deux trois truc comme les lifetimes explicites qui ont de quoi faire arracher quelques cheveux à ceux qui découvrent le langage.

Citation Envoyé par Neckara Voir le message
Après pourquoi pas, mais ça fait encore un n-ième langage à apprendre, tout le monde allant de son propre "successeur du C++"... Le problème est qu'on ne peut pas être un expert dans tous les langages.
C'est vrai que d'apprendre un langage supplémentaire peut être un obstacle. Le Rust a quand même un gros avantage quand tu ne le maitrises pas bien, c'est que quand tu fais une erreur d'utilisation, il va le plus souvent juste refuser juste de compiler.
C'est quand même plus sécurisant que des langages comme le C++ qui peuvent facilement introduire des erreurs pernicieuses s'ils sont mal employés.
6  0 
Avatar de abriotde
Membre expérimenté https://www.developpez.com
Le 20/07/2020 à 19:05
Aucun langage n'a eu autant l’approbation de la communauté pour remplacer C. Beaucoup ont dis qu'ils voulaient faire un remplaçant de C. Mais ils ont rarement convaincus et certainement pas pour remplacer C.

* Go à par exemple été conçus pour remplacer C, mais très vite on s'est rendu compte qu'il ne ferait pas l'affaire. Il remporte un certains succès pour remplacer la lourdeur de Java et des problème que fais Oracle.

* D n'a jamais convaincus que quelque barbus. Mais il n'a jamais vraiment révolutionné assez et C++ l'a rattrapé.

Bien d'autres ont voulu allié rapidité de C et simplicité de Python mais c'est techniquement impossible. C'est un peu comme si une voiture de circuit voulait être capable de tracter un poids lourd. En théorie on peu l'imaginer, mais en l'état actuelle des connaissance s'est ne pas être réaliste. On peut surmonter des obstacles mais un par un. Le voyage vers Proxima du Centaure n'est pas pour demain, Mars est un objectif plus réaliste et encore, la Lune représente encore des défis suffisant.

Rust apporte des idées nouvelles que l'on a pas connu depuis l'invention de la programmation Objet (enfin on en a connu mais qui n'ont pas convaincus comme la programation par Aspect). Ou plus récemment depuis LLVM mais cela ne concernait pas le langage lui même mais le compilateur.
6  0 
Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 20/07/2020 à 15:33
Citation Envoyé par redcurve Voir le message
Si ça vous intéresse regardez le projet Verona de Microsoft sur github c'est un playground autour de Rust pour résoudre des problématiques lié à la programmation système avec. Verona ne sera jamais utilisé comme tel mais ce qui est testé va en partie finir dans Rust pour certains points bien précis
Faudrait que tu te renseignes un peu sur le sujet avant de sortir un message ou les 3/4 (si ce n'est plus) est complétement faux.

Citation Envoyé par redcurve Voir le message
le projet Verona de Microsoft sur github c'est un playground autour de Rust
Rust et Verona n'ont aucun lien (si ce n'est pas qu'ils essayent de résoudre les mêmes problématiques mais différemment). Ils n'utilisent pas la même stack. Verona est implémenté en C++ tandis que Rust est self-hosté. Je ne sais ou tu es aller cherché sort cette histoire de playground.

Citation Envoyé par redcurve Voir le message
Verona ne sera jamais utilisé comme tel mais ce qui est testé va en partie finir dans Rust pour certains points bien précis
Non. Rust et Verona sont 2 choses distinctes faites par 2 équipes distinctes. Rien ne les empêche de s'inspirer l'un de l'autre mais vu qu'ils sont dans l'idée différent c'est peu probable que l'un contribue fortement à l'autre (et vice versa).
5  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 21/07/2020 à 10:33
Citation Envoyé par Neckara Voir le message
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.
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.
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.
5  0 
Avatar de walfrat
Membre éprouvé https://www.developpez.com
Le 22/07/2020 à 10:18
Citation Envoyé par Neckara Voir le message
Non, mais en informatique, on ne fait pas que développer des noyaux Linux, et heureusement !

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 (), ah bah moi c'est du JS (pour compatibilité avec un environnement Web), ah bah moi c'est du Python, non moi c'est du R, moi c'est direct en C++, n00b, je fais direct en assembleur... pfff amateurs, je code directement en écrivant chaque bits à la main sur le disque dur ".

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

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
5  0 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 20/07/2020 à 3:02
C'est intéressant de voir que des entreprises comme Microsoft ou Linus Torvald (qui ne jure que pas le C ) s'intéressent à Rust. Je comprends la philosophie derrière ce langage qui essaye de faire mieux que le C++ (malgré les nouvelles normes intégrant le concept de smart pointers), par contre je trouve que l'implémentation du concept de lifetime complexifie la lecture du code.
4  0 
Avatar de Freem
Membre émérite https://www.developpez.com
Le 21/07/2020 à 6:35
Citation Envoyé par SimonDecoline Voir le message

Encore une fois, ce n'est pas nouveau : les smart pointers de C++ existent depuis C++11, soit 9 ans. Aujourd'hui, la norme par défaut des compilateurs, c'est C++14 voire C++17.
Heu.... non. Le concept de smart pointer date d'au moins C++98, même s'il y avait des problèmes: std::auto_ptr. Sinon, il y avait aussi quelques articles qui traînaient sur la toile, notamment chez Dr.Dobbs sur le sujet.
Je ne dis pas que C++11 n'a pas amélioré les choses, hein, loin de la... ça a tellement changé le langage que je doute avoir été le seul à l'utiliser depuis avant 2010 (ce bon flag --std=c++0x...)
4  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 21/07/2020 à 11:23
Citation Envoyé par Markand Voir le message
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.
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.
4  0 
Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 22/07/2020 à 15:25
Citation Envoyé par Neckara Voir le message


Et tu as des langages où tu peux choisir ou non t'utiliser un garbage collector...
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...
C'est uniquement possible sur ceux qui ne sont pas dotés de GC de base (genre C/C++, Rust). Autrement si tu désactives le GC (et ce n'est pas toujours possible) sur les autres langages tu vas justes te retrouver avec des memory leaks de partout.
Faudra que tu m'expliques ce que tu fais dans le développement web alors. Parce que des langages ou tu peux désactiver le GC j'en connais pas des masses qui sont utilisés dans le dev Web.

Citation Envoyé par Neckara Voir le message

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...
Le WASM ne peut pas être considéré comme du langage assembleur. Il est similaire sur la forme mais sur le fond il est différent. Il y a certaines restrictions (interdiction des goto arbitraires, vérification des arguments au runtime, etc...) qu'on ne retrouve pas pour de l'assembleur classique. En plus le WASM est jité.

Citation Envoyé par Neckara Voir le message

Va donc devenir expert dans 7 langages différents en comprenant toutes leurs nuances, leurs bibliothèques principales... et on en reparle...
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 ><.
Personne ne te demande de devenir expert dans plein de langages. Tu n'as qu'à choisir un petit nombre (au hasard juste Js) et t'y tenir. Tu n'arriveras pas à me faire croire qu'une bonne maitrise de Js (et potentiellement HTML + CSS mais qui ne sont pas des langages de programmation) ne suffit plus pour trouver un travail. Si c'est le cas c'est soit que tu habites dans un trou pommé ou que tu n'arrives pas à décrocher un poste (et une remise en question serait la bienvenue)

Citation Envoyé par Neckara Voir le message

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.
Ce qui est valable pour toi ne l'est pas pour les autre. Je ne m'en fout pas de l'optimal. Je suis content que plein de langages aient été inventés pour éviter de rester coincés avec du Cobol ou de l'asm. Cela vaut aussi pour ceux qui n'existent pas encore mais qui viendront rendre mon travail plus agréable dans le futur. Et ce n'est pas toujours possible ni souhaitable de rajouter des concepts à un langage. Par exemple, c'est impossible de rétro-fiter le système d'ownership de Rust à C++.

Citation Envoyé par Neckara Voir le message


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.
Ça sort d’où ce but ? C'est toi qui le défini pour tout le monde ? Ou alors tu parles uniquement pour un but professionnel? Mais alors les gens de l'INRIA qui développe des langages sont payés pour rien ? Mais alors Dennis Ritchie glandait quand il inventait le C ou là c'était justifié ?
Citation Envoyé par Neckara Voir le message


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.

Là on sent tout de suite que tu n'a pas testé le langage parce que si ce qui te choques le plus c'est les parenthèses optionnelles autour du if (autrement la syntaxe est très C++) c'est que tu n'as jamais fait de "combat" avec le borrow checker qui est la feature centrale de Rust. Autrement dit, tu formules une critique sans avoir testé ni même lu ce que Rust rend possible.

Citation Envoyé par Neckara Voir le message

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.
Les macros de Rust sont hygiéniques en Rust et beaucoup plus puissante qu'en C++. Les 2 ont rien à voir. Ensuite Rust a aussi l'équivalent des constexpr et d'autre features dans cette lignée sont prévu à l'horizon.

Citation Envoyé par Neckara Voir le message

Le format des chaînes de caractère est bizarre, ils auraient mieux fait de reprendre celle du JS
Juste non en fait.

Citation Envoyé par Neckara Voir le message

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...
Pour un nouveau langage tu as surtout pas pris le temps de tester et ça se voit au contenu de ce que tu post depuis le début. Respectes les autres (et toi par la même occasion) et essayes Rust (ou au moins documentes toi dessus) avant de sortir un florilège de posts vides de sens qui ne sont même pas lié au topic de base (à savoir l'intégration de Rust dans le Kernel Linux)
6  2