IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

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 !

Microsoft, Google et ARM viennent grossir les rangs de la Bytecode Alliance
Pour faire avancer WebAssembly au-delà du navigateur

Le , par Stéphane le calme

20PARTAGES

23  0 
Fin 2019, dans un effort commun visant à faire de WebAssembly un runtime informatique multiplateforme, les entreprises Mozilla, Fastly, Intel et Red Hat ont annoncé le lancement de la Bytecode Alliance. Cette initiative architecturée autour de WebAssembly est axée sur la fourniture d’un bytecode sécurisé par défaut qui peut être exécuté depuis un navigateur Web, un ordinateur de bureau ou une plateforme IoT/embarquée.

Pour rappel, WebAssembly a été présenté comme une architecture de jeu d’instructions virtuel avec de nombreux cas d’utilisation capable de prendre du code écrit dans des langages de programmation autres que JavaScript et d’exécuter ce code sur une plateforme spécifique – du moins à l’origine -, un navigateur en l’occurrence. Cette solution devrait également permettre aux applications complexes – telles que les jeux vidéo immersifs en 3D, le design informatisé ou l’édition d’images et de vidéos – de fonctionner de façon optimale sur les plateformes cibles. Grâce à WebAssembly, des développeurs seraient par exemple en mesure de coder leurs applications en C, C++ ou en Rust et de faire exécuter ces programmes à la vitesse native sur un navigateur Web, sans avoir à repasser par JavaScript avec les contraintes que cela impose.

Selon les promoteurs l’initiative, la montée en puissance du Cloud et des périphériques IdO fait que les développeurs exécutent du code non fiable dans de nouveaux environnements, ce qui soulève de nouveaux problèmes, notamment en matière de sécurité et de portabilité. La Bytecode Alliance devra fournir une base permettant aux développeurs d’exécuter en toute confiance du code non fiable sur n’importe quelle infrastructure, système d’exploitation et périphérique. Cette communauté open source se focalisera sur la mise en place d’un environnement d’exécution et de chaînes d’outils linguistiques associées – incluant cargo-wasi, wat et wasmparser – qui offrent sécurité, efficacité et modularité sur une large gamme d’architectures et de périphériques. Le projet devrait s’appuyer sur les normes existantes telles que WebAssembly et WebAssembly System Interface (WASI).


De nouveaux arrivants

De nouveaux noms ont rejoint l'Alliance. Outre Microsoft, les nouveaux membres sont: Arm, DFINITY Foundation, Embark Studios, Google, Shopify et University of California San Diego.

Dans une déclaration, Bobby Holley, ingénieur distingué chez Mozilla et membre du conseil d'administration de Bytecode Alliance, a décrit le développement logiciel aujourd'hui comme un ensemble de compromis difficiles. « Si vous voulez construire quelque chose de grand, il n’est pas réaliste de créer chaque composant à partir de zéro », a déclaré Holley. « Mais le fait de s'appuyer sur une chaîne d'approvisionnement complexe de composants provenant d'autres parties permet à un défaut n'importe où dans cette chaîne de compromettre la sécurité et la stabilité de l'ensemble du programme. Mozilla a aidé à créer WebAssembly pour permettre au Web de se développer au-delà de JavaScript et d'exécuter plus de types de logiciels à des vitesses plus rapides. Mais au fil de sa maturation, il est devenu clair que les propriétés techniques de WebAssembly – en particulier l'isolation de la mémoire – avaient également le potentiel de transformer le développement logiciel au-delà du navigateur. Plusieurs autres organisations partageaient ce point de vue et nous nous sommes réunis pour lancer la Bytecode Alliance en tant que partenariat industriel informel à la fin de 2019 ».

« Des outils comme les conteneurs peuvent fournir un certain degré d'isolation, mais ils ajoutent des frais généraux substantiels et sont peu pratiques à utiliser avec la granularité par fournisseur. Et toutes ces dynamiques renforcent les avantages des grandes entreprises qui disposent des ressources nécessaires pour gérer et auditer soigneusement leurs chaînes d'approvisionnement ».

La Bytecode Alliance considère WebAssembly comme un moyen de rendre le code composable, sûr et rapide sans sacrifices. Dans un communiqué, elle a déclaré :

« Ces organisations partagent la vision d’un écosystème WebAssembly qui corrige les fissures dans les fondations logicielles d’aujourd’hui qui empêchent l’industrie et ses chaînes d’approvisionnement logicielles d'aller vers un avenir sécurisé, performant, multiplateforme et multiappareil. Les membres de la Bytecode Alliance estiment qu'une collaboration multipartite efficace est essentielle pour réaliser cette vision des fondations logicielles qui permettent à la sécurité, à l'efficacité et à la modularité de coexister sur la plus large gamme de dispositifs et d'architectures.

« La Bytecode Alliance, fondée en 2019, a contribué à attirer l'attention sur les faiblesses inhérentes aux modèles prédominants de création de logiciels, qui reposent fortement sur la composition de milliers de modules tiers sans frontières de sécurité entre eux. Ces faiblesses dans la chaîne d'approvisionnement des logiciels ont historiquement été déterminantes pour violer les systèmes gouvernementaux, les services d'infrastructure critiques et un grand nombre d'entreprises, ainsi que pour voler les informations personnelles de centaines de millions, voire de milliards de personnes. La résolution de ces défis exigera des efforts dans de nombreuses industries. Avec un modèle de gouvernance ouvert et une liste croissante d'organisations membres, la Bytecode Alliance intensifiera ses efforts pour apporter des solutions à cet espace à l'appui de sa mission.

« Les organisations passionnées par la contribution à cette mission et la construction de nouvelles fondations plus sûres pour le cloud, la périphérie, l'Internet des objets et de nombreux autres environnements et plateformes sont invitées à postuler pour devenir membres. Les demandes d'adhésion seront examinées sur une base continue, mais celles soumises dans un proche avenir auront la possibilité de participer aux élections du conseil d'administration au second semestre 2021 ».

Les membres fondateurs ont partagé un tas d'outils WASM avec Bytecode Alliance, y compris des environnements d'exécution, des composants d'exécution et autres.

Maintenant avec Microsoft, Google et Mozilla à bord, la Bytecode Alliance bénéficie du soutien de trois des quatre principaux fournisseurs de navigateurs. L'éditeur de Safari Apple est le seul fournisseur majeur de navigateurs qui est absent. Avec un soutien plus large, l'alliance se donne une meilleure chance de survie à long terme.

« WebAssembly et la nouvelle spécification WebAssembly System Interface (WASI) permettent aux solutions cloud natives de devenir plus sécurisées par défaut et aident à résoudre les problèmes informatiques dans une variété d'environnements », a déclaré Ralph Squillace, directeur principal du programme Microsoft d'Azure Core Upstream et membre du conseil d'administration de Bytecode Alliance.

WASI est une interface système pour WebAssembly qui permet au code en dehors d'un navigateur de communiquer avec plusieurs systèmes d'exploitation.

Le travail de Microsoft sur WebAssembly inclut sa sortie de Blazor WebAssembly, qui permet aux développeurs C# et .NET de créer des applications qui s'exécutent dans le navigateur avec WebAssembly, mais fonctionnent comme une application de bureau native, également appelée Progressive Web Apps.

Blazor WebAssembly est l'une des quatre versions du projet Blazor de Microsoft, qui comprend le rendu Blazor Server pris en charge pour les applications Web, un moteur de rendu Electron et les liaisons expérimentales Mobile Blazor récemment publiées pour la création d'applications iOS et Android natives en utilisant C# et .NET au lieu de JavaScript. .

Sources : Bytecode Alliance, Mozilla

Voir aussi :

Wasmer : un runtime open source pour l'exécution de WebAssembly sur un serveur, tout en prenant en charge l'API Wasm-C
Node.js 14 est disponible avec un support expérimental de WebAssembly System Interface (WASI), la fonctionnalité "rapport de diagnostic" est maintenant stable
Zig 0.6.0 est disponible, le langage de programmation polyvalent prend en charge LLVM 10, WebAssembly, Windows et bien d'autres

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

Avatar de Captain Spic
Nouveau membre du Club https://www.developpez.com
Le 01/05/2021 à 0:35
C'est assez déprimant quand tu tombes sur un article cool, sur une technologie cool qui a un potentiel assez énorme, et qu'en dessous, il y a deux commentaires archi négatifs et ce sans justifications valables...

Il faut savoir que Java et .NET, qui sont les deux grosses références en terme d'exécution au travers de bytecode, n'ont jamais réussi à fédérer plus de communautés que la leur.
Avec WASM, on peut dire qu'il y a eu un engouement certain de la part d'à peu près toute les communautés, y compris chez ces deux compères (la liste des projets de compilation vers WASM).

Déjà à la base le projet est assez génial puisque qu'il permet à n'importe quel langage de pouvoir rivaliser avec JavaScript et sa fullstack.
Les aficionado du C++ pourront donc utiliser leur langage de prédilection pour exécuter du code côté client.
Du coup, même ceux qui haïssent JavaScript, devraient être content : ils n'ont plus besoin de l'utiliser pour monter une application web !

Et maintenant, c'est encore mieux, puisque les enseignements appris chèrement avec l'évolution des usages du web, dont WASM hérite vont pouvoir déborder du web et en faire profiter le développement "natif".
(En plus de pouvoir faire communiquer deux langages différents de manière plus simples et efficace et ce, peu importe la plateforme.

Franchement, le potentiel est là et vu les efforts investis on peut espérer de belles choses à l'avenir !
Enfin bref, ça vaut vraiment pas le coup de venir rager
6  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 02/05/2021 à 8:42
Citation Envoyé par archqt Voir le message
En gros c'est du "ByteCode" qui est exécuté. Par contre la vitesse native, non, ça ne pourra jamais aller aussi vite que des instructions assembleur. Sauf si bien sûr le byte code est retraduit en instruction assembleur avant .
Je suppose que c'est cela qui est fait, du moins ce que je ferais moi, un code intermédiaire comme celui qui sort de LLVM, puis une traduction de cet assembleur universel vers l'assembleur de la cible.

Par contre s'il y a GC on aura forcément des pertes par rapport à une application pure C/C++/Rust par exemple.
Justement, un gros avantage de WASM par rapport à JavaScript, c'est qu'il n'impose pas de notions de haut niveau comme un GC ou un typage dynamique. Un WASM produit à partir d'un langages de type C, C++ ou Rust peut donc théoriquement être compilé en quelque-chose de relativement similaire.
Dans la pratique il y a quand même des écarts dus à certaines contraintes de sécurité, indispensables pour des code tiers téléchargés à la volée (protection contre les buffer overflow et les failles de type spectre notamment). De plus les compilateurs WASM, vont généralement, dans un premier temps, ne pas optimiser autant qu'ils le pourraient pour privilégier la vitesse de compilation et donc leur permettre de démarrer l’exécution quasi immédiatement, ce qui est généralement ce que l'on attend dans un contexte web. Seul les codes relativement couteux en temps d’exécution seront recompilés avec les meilleures optimisations.

Le fonctionnement général du Wasm est en effet comparable au LLVM IR. Avec son projet pNaCL, Google souhaitait d'utiliser directement le LLVM IR comme bytecode, Mozilla de son coté, avec asm.js, proposait d'utiliser un sous-ensemble de JavaScript. Wasm est né de la mise en commun de leurs idées d'une manière plus propre, avec bytecode spécifiquement conçu pour être adapté aux contraintes du Web. Comparé à ces représentations intermédiaires, il est plus indépendant de la plateforme, plus compact a télécharger, plus rapide a compiler, plus sécurisé.

Citation Envoyé par SimonDecoline Voir le message
Quels enseignements par exemple ?
J'ai plutôt l'impression que le web frontend a perdu du temps à refaire ce qui existait déjà dans le natif.
En effet, mais dans le cadre d'une exécution dans le navigateur il y a des contraintes de portabilité et de sécurité qui sont ignorées par les développeurs natif, d'où la catastrophe ActiveX.
Les Applets ont été la première tentative de résoudre le problème d'exécution dans le navigateur mais elle ont échoué pour des raisons à la fois techniques, et politiques. Techniquement, ça imposait une architecture trop contraignante, trop liée au langage Java lui même, pas assez orienté vers les performances. Politiquement, Java n'a jamais cherché a être une norme du web, c'est resté un produit appartenant à Sun, mal intégré. L'opposition a peine cachée de Microsoft n'a rien arrangé.
Il y a eu d'autres tentatives, comme Flash, Active X, NaCL, asm.js,... qui péchaient toutes plus ou moins a différents niveaux : intégration, portabilité, sécurité, ... pour la simple et bonne raison que c'était des initiatives poussées par des acteurs externes qui fournissaient une solution taillée pour leur propres objectifs et pas le Web en général.

Webassembly est vraiment une action commune des principaux acteurs du Web, bâtie sur l'expérience de ces projets et qui vise a traiter au mieux les besoin d'un bytecode du Web et qui a été penser pour traiter au mieux à la fois les problématiques de performance, de portabilité, de sécurité et d'intégration a l'écosystème Web.
4  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 01/05/2021 à 7:33
Citation Envoyé par Jeff_67 Voir le message
Le point faible du web, c'est JavaScript. Or avec WebAssembly, il n'est à ma connaissance pas possible d'interagir avec le navigateur sans passer par un bout de code JavaScript.
Pour le moment juste une petite partie des API Web est disponible directement (principalement Canevas et webgl), mais a terme toute les API du navigateur devraient être accessibles sans passer par JavaScript. Le souci pour le moment c'est que la plupart des API comme le DOM utilisent des objets qui sont managé par le Garbage Collector du navigateur. Donc avant de les rendre disponible, il faut rendre WASM capable d'interagir avec le GC ce qui nécessite encore des travaux
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 02/05/2021 à 10:56
Citation Envoyé par Madmac Voir le message
- Parce que le passé est garant de l'avenir.
C'est juste une jolie phrase taillée pour la philosophie de comptoir, mais dans la pratique sans aucun fondement. En réalité, le passé est rarement le garant de l'avenir, car les situations ne se représentent quasiment jamais deux fois a l'identique. C'est particulièrement vrai dans le cas qui nous concerne.

Citation Envoyé par Madmac Voir le message
Si Microsoft est impliqué, tu peux est certain que cela va finir en eau de boudin. Microsoft est sectaire.
La situation actuelle de WASM n'a pas grand chose a voir avec l'époque de Active X dans le navigateur. Les technologies sont sensiblement différentes et surtout, Microsoft n'est pas maitre a bord, c'est juste un membre parmi d'autre. De plus et il n'a pas de position particulièrement dominante, sur le domaine visé par Wasi (serveur et IOT), il est même plutôt un outsider. Même au niveau du contrôle des techno Web, il s'est fait voler sa position par Google.

Citation Envoyé par SimonDecoline Voir le message
Oui d'accord mais tout ça, ça reste spécifique au web/navigateur. Ma question était sur les "enseignements du web frontend qui vont faire profiter le dev natif".
En effet, sous cet angle là, l'intérêt est carrément discutable : le natif à déjà récupéré depuis longtemps ce qu'il avait à récupérer du front (xaml, styles,... ), il n'y a pas vraiment besoin de Wasm pour ça.
L'interet de Wasm hors du web, c'est plutôt pour avoir un système de sandbox plus léger qu'avec la virtualisation ou un conteneur.
2  0 
Avatar de Madmac
Membre expérimenté https://www.developpez.com
Le 03/05/2021 à 21:04
Citation Envoyé par Uther Voir le message
C'est juste une jolie phrase taillée pour la philosophie de comptoir, mais dans la pratique sans aucun fondement. En réalité, le passé est rarement le garant de l'avenir, car les situations ne se représentent quasiment jamais deux fois a l'identique. C'est particulièrement vrai dans le cas qui nous concerne.
Pas du tout

par exemple
Code : Sélectionner tout
1
2
3
4
5
begin
File.open("./planets.ini").each { |planetname| planets_temp.append( planetname) }
rescue SystemCallError => e
   print "Error: ./planets.ini missing, loading default values."
end
Ce code fonctionne sous Mac et Linux, mais pas sous Microsoft. Vois-tu voir pourquoi? Et leur foutu terminal qui ne comprend pas NCurses.

Citation Envoyé par Uther Voir le message
La situation actuelle de WASM n'a pas grand chose a voir avec l'époque de Active X dans le navigateur. Les technologies sont sensiblement différentes et surtout, Microsoft n'est pas maitre a bord, c'est juste un membre parmi d'autre. De plus et il n'a pas de position particulièrement dominante, sur le domaine visé par Wasi (serveur et IOT), il est même plutôt un outsider. Même au niveau du contrôle des techno Web, il s'est fait voler sa position par Google.
La similarité est qu'ils vont pouvoir écrire autre chose que des cookies sur ton disque . Et cela représente un énorme problème. Et mème Microsoft n'est qu'un joueur parmi les autres, je n'ai qu'à penser à Explorer pour imaginer les milles et une façon d'empoisonner ce projet.

Citation Envoyé par Uther Voir le message
En effet, sous cet angle là, l'intérêt est carrément discutable : le natif à déjà récupéré depuis longtemps ce qu'il avait à récupérer du front (xaml, styles,... ), il n'y a pas vraiment besoin de Wasm pour ça.
L'interet de Wasm hors du web, c'est plutôt pour avoir un système de sandbox plus léger qu'avec la virtualisation ou un conteneur.
Là j'ai du mal à te suivre. Pour le moment Wasm se limite à Javascript. Alors un navigateur suffit. Et coté serveur Node te permet tester ton code.
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 03/05/2021 à 23:10
Citation Envoyé par Madmac Voir le message
Ce code fonctionne sous Mac et Linux, mais pas sous Microsoft. Vois-tu voir pourquoi? Et leur foutu terminal qui ne comprend pas NCurses.
C'est un peu hors sujet, là. Mais si tu veux dire que, tous les outils ne sont pas toujours 100% multi plateformes, en effet c'est vrai, et Microsoft et loin d'être le seul coupable dans le domaine. Le fait qu'ils collaborent à WebAssembly et WASI, qui sont des technologies qui visent justement à améliorer l'interopérabilité, c'est justement plutôt un bonne nouvelle.
L'époque ou Microsoft essayait d’écraser de son poids les efforts de standardisation est révolue depuis longtemps. Même s'ils le voulaient ils ne sont plus en position de force pour le faire.

Citation Envoyé par Madmac Voir le message
La similarité est qu'ils vont pouvoir écrire autre chose que des cookies sur ton disque . Et cela représente un énorme problème. Et mème Microsoft n'est qu'un joueur parmi les autres, je n'ai qu'à penser à Explorer pour imaginer les milles et une façon d'empoisonner ce projet.
...
Là j'ai du mal à te suivre. Pour le moment Wasm se limite à Javascript. Alors un navigateur suffit. Et coté serveur Node te permet tester ton code.
Je pense que tu as mal compris ce que sont WebAssembly et WASI.
WASM est un bytecode générique qui peut théoriquement être produit a partir de n'importe quel langage, avec des performance potentiellement proche du natif.

Le premier usage historique de WebAssembly est, comme son nom l'indique, dans le cadre du navigateur Web. Pour cet usage, il n'aura accès qu'aux API Web existantes et rien de plus. Donc il n'apporte aucune nouvelle possibilité technique au navigateur par rapport JavaScript. Il permettra juste d'être plus performant et d'utiliser d'autres langages de manière plus propre.

Le but de la Bytecode alliance, dont parle l'article, est de développer WASI, une API qui permettra l'usage du Bytecode WebAssembly sans navigateur. Le but premier est de pouvoir mettre en place un système de sandbox pour des environnement de type serveur, plutôt qu'un système de conteneur ou de virtualisation. Mais dans ce cas là, malgré son nom, WebAssembly n'a plus aucun lien avec le navigateur. WASI sera une API adaptée aux besoin d'un ordinateur complet qui sera utilisable dans des machines virtuelles dédiés. Elle ne sera jamais intégrée aux navigateurs.

La seule chose en commun entre une appli WebAssembly sur navigateur et une appli WASI, c'est le format du bytecode.
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 06/05/2021 à 22:02
Citation Envoyé par Madmac Voir le message
Ok, là je comprend. Je vois pas vraiment l'intérêt de faire à distance ce que peut-être fait sur son propre ordinateur. J'imaginais quelque chose comme les JARS de Java. Je ne crois pas que cela va révolutionner le monde de l’informatique.
Il ne s'agit pas de faire les choses à distance, enfin pas forcément. Les Applications WASI seront des applications normales, tout a fait utilisable en local. Un fichier wasm compilé pour utiliser WASI est l'équivalent d'un fichier .class. La JVM executant le code Java est juste remplacée une VM WebAssembly et la bibliothèque standard Java est remplacée par WASI.

L'avantage de WASI est que :
- il assure une encapsulation des IO, à la manière d'un conteneur Docker, mais au niveau de la VM WASM et pas du système, ce qui devrait être moins couteux en performance.
- L'application peut théoriquement être écrite dans n'importe quel langage.
- Le WebAssembly étant conçu pour fonctionner avec des langages de bas niveau, il permet de tirer de meilleures performances qu'une JVM taillé spécifiquement pour le Java
- Son utilisation quasi transparente, ce qui permet une prise en main quasi immédiate pour les utilisateurs et l'adaptation simple pour les applications existantes.
2  0 
Avatar de archqt
Membre éprouvé https://www.developpez.com
Le 01/05/2021 à 14:50
En gros c'est du "ByteCode" qui est exécuté. Par contre la vitesse native, non, ça ne pourra jamais aller aussi vite que des instructions assembleur. Sauf si bien sûr le byte code est retraduit en instruction assembleur avant .
Je suppose que c'est cela qui est fait, du moins ce que je ferais moi, un code intermédiaire comme celui qui sort de LLVM, puis une traduction de cet assembleur universel vers l'assembleur de la cible.

Par contre s'il y a GC on aura forcément des pertes par rapport à une application pure C/C++/Rust par exemple.
1  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 05/05/2021 à 21:32
J'ai très bien lu, mais si tu sembles savoir ce qu'est un bytecode, je confirme que tu n'as visiblement pas bien saisi pas la portée de WASI.

C'est pas seulement que l’exécution du code pourra avoir lieu en dehors du navigateur, mais quelle le devra. WASI ne sera jamais implémenté dans les navigateurs. Elle ne sera accessible qu'à des VM exécutées comme des applications standalone, à la manière qu'une application Java, Python, ...
1  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 11/05/2021 à 8:31
Citation Envoyé par tralloc Voir le message
Salut les gens.
Ca fait quelques années que je regarde WASM de loin avec une envie terrible sous-jacente que ça marche et que je puisse l'utiliser que ce soit employé dans les frameworks gourmands...
Les framework web, c'est un peu hors sujet dans le cadre de cet article vu que la bytecode alliance travaille à utiliser le bytecode de WebAssembly hors du cadre du Web.

Citation Envoyé par tralloc Voir le message
J'ai voulu essayer un peu il y a quelques années. De faire une fonction, de la compiler, mais c'était hyper galère et pour l’utiliser dans une page je n'avais pas trop compris.
Si tu as regardé au début de WebAssembly c'est normal, tout était loin d’être prêt, ça en était encore au stade de l’expérimentation . Maintenant la situation est bien meilleure même s'il manque encore des chose importante pour que l'utilisation vaille vraiment le coup en dehors des cas ou on a besoin de performance. La prochaine grosse étape, c'est quand WebAssembly pourra accéder directement à toutes les API web.

Citation Envoyé par tralloc Voir le message
Savez vous si les outils se démocratisent, quels sont-ils, si ça va arriver ?
Est-ce qu'on peut déjà programmer en RUST ou en est-on encore au C ? Et des langages comme python, y a-t-il des portages... ?
Pour ce qui est de Rust, c'est clairement le langage qui a fait, dès le début, le plus d'effort pour supporter le WebAsembly, même plus que le C. Le support est intégré de base dans le compilateur et il y a pas mal d'outils très utiles disponibles, dont un générateur automatique d'interface avec JavaScript, une bibliothèque qui donne accès a toutes les API Web, même si elle passe par l'intermédiaire de JavaScript pour celles qui ne sont pas directement accessibles pour le moment.
Avec Rust, on peu clairement utiliser WebAssembly en production, ce qui n'est pas vraiment le cas de tous les langages.
1  0