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