À la découverte de Web Assembly

0:14 Bonjour à tous, je m'appelle Philippe Ensarguet, je suis actuellement CTO chez Orange Business, qui est donc la marque du marché entreprise d'Orange. Je suis également advisor pour plusieurs fonds d'investissement, board advisor pour plusieurs startups dans la tech, et bien sûr, très fier d'être dans ce collectif Tech.Rocks qui fédère les leaders de la tech, et notamment en France. Donc bienvenue à notre meet-up à la découverte de WebAssembly. J'ai prévu une intro très courte, mais pour pouvoir camper un peu le décor qui me paraissait important. En 2022, on s'est vraiment rendu compte que WebAssembly, qu'on appelle également par raccourci WASM, a été littéralement catapulté sous les feux de la rampe. On a vu plein de nouvelles startups émerger, arriver sur la scène. On a vu des acteurs de la big tech commencer à proposer du tooling, des environnements. De plus en plus d'entreprises marquent leur soutien à cette technologie.

1:16 Et grâce à trois propriétés essentielles qu'on va visiter dans ce meet-up, que sont la performance, la sécurité. Et également la portabilité. On observe des organismes de standardisation, par exemple, comme la BAM. Icoid Alliance, qui lance un certain nombre de normes pour accompagner le développement de la technologie et soutenir cet écosystème. On a un nombre d'événements autour de Wasm qui explosent un peu partout, notamment par exemple comme le Wasm Day. Et pour terminer sur un élément de perspective peut-être un peu plus business, je pense que vous avez tous vu l'année dernière passer l'annonce du rachat de Figma, qui est peut-être l'une des plus grandes sociétés utilisatrices de Wasm par Adobe pour la somme de 20 milliards de dollars. Donc, voilà, pour toutes ces raisons, on peut se dire qu'il y a un minima à explorer, à comprendre, et c'est vraiment l'objectif de ce meet-up que l'on a concocté avec Benjamin et avec Philippe.

2:18 Et pour vous accompagner dans ce voyage, j'aurai le plaisir d'être accompagné par Philippe et Benjamin, que j'ai le plaisir d'accueillir avec moi sur scène. Messieurs, si vous voulez bien me rejoindre. Bonjour à tous les deux. Hello. Bien le bonjour. Eh bien, peut-être qu'avant de démarrer dans le vif du sujet, c'est peut-être intéressant de comprendre qui vous êtes. Du coup, Benjamin, tu es qui? Tu fais quoi? Comment tu es tombé dans l'histoire de Wasm? Alors moi c'est Benjamin Coenen du coup, ravi d'être là, merci pour l'invitation. Pour l'instant je suis dev chez Apollo GraphQL. Pour ceux qui ne connaissent pas vite fait, GraphQL, c'est une spec qui est un peu concurrente à REST si on fait des API web. Et du coup, Apollo GraphQL fait un peu tout ce qui est tooling autour de GraphQL. Et moi, sur ma partie, je développe en open source un produit qui s'appelle le router, qui permet de faire du microservice en GraphQL.

3:22 Et hormis ça, j'essaie d'être plutôt investi dans la communauté open source autour de Rust, un peu de Wasm aussi. Et quand j'ai l'occasion de faire des petits talks ou d'essayer de partager un peu mes passions comme aujourd'hui, je le fais avec plaisir. Et comment je suis tombé... Dans Wasm, comment j'en ai fait. En clair, c'est principalement avec mon ancienne boîte qui s'appelait Cosmian, qui est une boîte française qui bosse dans la cryptographie. Rien à voir avec la blockchain, vraiment la cryptographie pour sécuriser les données et tout ça. Et en fait, on avait des besoins un peu spécifiques, comme réutiliser des briques de crypto qu'on a écrites en Rust, pour pouvoir les réutiliser dans le front ou alors dans d'autres langages. Et notamment un truc un peu spécifique, mais je pense qu'on s'y attendra un peu plus tard, mais on a développé un compilateur expérimental qui prend en entrée du WASM, du WebAssembly, et qui le compile vers un autre bytecode. Mais on aura l'occasion de s'y attarder plus tard, je pense. Super, merci beaucoup Benjamin. Philippe, même question pour toi.

4:24 Ok, bon alors moi aussi, ravi d'être là bien sûr, et faire ça avec vous deux. Donc, Philippe Charriere, je suis Customer Success Engineer chez GitLab. Donc, aucun rapport avec Wazem, en fait. J'aide les équipes Customer Success sur des sujets techniques et métiers. Comment je suis arrivé à WebAssembly? J'essayais justement de raccrocher le fil. J'avais eu une époque, il y a très longtemps, eu accès à un workshop au Jack Summer Camp fait par Oratio, d'Ebrel de chez OVM. Et j'avais trouvé ça pas intéressant, trop compliqué, on ne pouvait rien faire, ce n'était pas drôle. Et puis, après le confinement, je suis parti en vacances. En promettant à ma femme que je n'amènerais pas d'ordinateur pendant les vacances. Je suis parti juste avec mon iPad et j'ai triché, j'ai utilisé Gitpod pour commencer à apprendre le Go. Et en cherchant dans les tutoriels, je suis tombé sur un tutorial Wasm et Go dans le navigateur.

5:26 Et en fait, j'ai oublié d'apprendre vraiment ce que je voulais faire en Go. Et j'ai commencé à mettre la main dans Wasm et j'ai passé tout mon été dessus pour au final me dire, il faut que j'écrive un bouquin là-dessus. Et puis voilà, ça a commencé comme ça. Oui, j'en profite également. Tu fais bien. Moi, je pense que le livre que tu as écrit est un très bon point de départ. Et je trouve qu'il a une vertu extrêmement précieuse. C'est que tu as packagé tout l'environnement avec la chaîne de production pour pouvoir être en zone extrêmement rapidement. Donc, pour tous ceux qui ont vraiment envie de commencer à jouer avec et à très rapidement voir des résultats, honnêtement le livre que tu as écrit est pour moi une très très bonne référence pour pouvoir commencer Je te coupe, Philippe, juste parce que c'est super sympa, mais surtout, ne l'achetez plus parce qu'en fait, il est déjà obsolète. Donc, je suis en train de penser à une suite avec un nouveau packaging et tout ça. Oui, c'est déjà une partie.

6:30 des choses sont déjà fausses ou ne fonctionnent plus. Bon, d'accord. OK. J'aurais essayé. Avant de rentrer dans le vif du sujet, je rappelle juste qu'on vous avait le Q&A pour nous poser les questions. N'hésitez pas à les liker pour nous aider à prioriser. Bien sûr, si vos questions sont dans le flot, l'équipe essaiera de les prendre au fur et à mesure. Et puis derrière, sinon, on les traitera plutôt en fin de meet-up. Je propose qu'on démarre directement et qu'on rentre dans le vif du sujet. Alors moi, la première question que j'ai envie de vous poser, d'abord, quelles sont les origines, quels sont les premiers cas d'usage, d'où est-ce que tout ça vient? Je ne sais pas, Benjamin, est-ce que tu veux commencer à nous donner ton point de vue là-dessus? En clair, je pense que la première version est sortie vers 2015-2016. L'idée, à la base, c'était de faire tourner un autre langage que JavaScript dans le browser. Donc, essayer d'amener peut-être d'autres personnes à pouvoir développer des choses.

7:33 Au niveau du navigateur. Et en fait, ça a été initié par le W3C, c'est toujours maintenu par le W3C, qui est le consortium autour du web. Et en fait, la réalité derrière, c'est que souvent, c'est plus poussé par des boîtes que par le consortium en lui-même. Donc, l'évolution de WebAssembly au niveau browser, en tout cas, elle s'est faite pas mal. avec la poussée de Mozilla et tout ça, qui a pas mal bossé sur ce sujet et qui l'a intégré assez rapidement dans son navigateur Firefox. Et jusqu'à, en fait, je pense il y a deux ans, ils ont fait une grosse vague de licenciements chez Mozilla. Et si je me souviens bien, je pense qu'ils ont viré quasiment, je pense même toute l'équipe qui bossait autour de WebAssembly qui était chez Mozilla. Et chose plutôt pratique, c'est que cette équipe a été reprise telle qu'elle, réembauchée par Fastly, qui lui aussi avait des besoins de faire évoluer cette spec.

8:36 Mais du coup, Mozilla, lui, c'était plus faire évoluer la spec côté browser. Et Fastly, lui, c'est plus pour faire du... Edge computing, des choses comme ça, et donc plus côté back-end, c'est aussi ça qui est intéressant de voir l'évolution en fonction de quelle boîte pousse un peu ou bosse un peu sur l'aspect. Donc en gros, ce que tu es en train de nous expliquer, de nous partager Benjamin, et Philippe, si tu veux rebondir dessus, je sais que tu as eu quelques talks là-dessus, j'ai l'impression que WebAssembly finalement s'est échappé ou est sorti du navigateur, mais du coup, on le retrouve un peu où? Et finalement, quels en sont les cas d'usage pour toi, Philippe? Alors, je rajouterai une précision à ce qu'a dit Benjamin. Après, c'est pareil, on peut se contredire. être d'accord ou pas d'accord. Pour moi, 110, c'était aussi une évolution du projet Azum.js qui était fait par Mozilla aussi en 2013.

9:42 Donc, ça doit concorder avec le 2015, on parlait Benjamin. Et qui était, alors lui, c'était plus... Trouver un moyen d'accélérer JavaScript, en fait, et de l'optimiser. Et c'est le grand-père ou le papa de Wasm, on va dire. les bases. Après, sur les cas d'usage, les premiers, ils ont été dans le navigateur. Wazen, c'était fait pour dans le navigateur. Alors, des gens disent que c'est fait pour remplacer JavaScript. Je pense que c'est plutôt fait pour bosser avec JavaScript. Je ne pense pas que ça remplacera JavaScript. Voilà. C'est un nid d'âne avec Wazen. Oui. Il y en a qui aiment. Il y a des frameworks complets pour faire du pur web en Wazen sans JS. Mais c'est un peu… Moi, je ne peux pas. En plus, il faut faire attention au Wazen. Les gens retiennent surtout le côté compilation native et ça va être super rapide. Mais en fait, la VM JavaScript, Elle est super optimisée et des fois, elle va plus vite que Wasm dans certains cas.

10:46 Donc, il ne faut pas tout casser et tout réécrire. Mais le premier cas d'usage, il était dans le navigateur pour amener des fonctionnalités en plus au navigateur pour aider à apporter des choses existantes, mais dans le navigateur. Par exemple, maintenant, AutoCAD, il n'y a plus besoin de l'installer. On peut avoir un AutoCAD. Dans son navigateur sans rien installer, sans plugin. Il faut que le navigateur soit récent et sache utiliser WebAssembly. Mais il y a pas mal de choses qui sont portées comme ça relativement facilement. C'est souvent en C, C++, et puis on le voit de plus en plus en Rust. Il y a Unity 3D aussi qui permet de faire du jeu dans le navigateur. Et les jeux sont plutôt bien fournis. Et un autre exemple, moi, celui que j'aime bien, c'est Google Earth. Moi, depuis que je suis tout petit, je fais une fixette sur les cartes. J'avais obligé mes parents à m'acheter une carte en relief du Vercors qui est moche à faire peur, mais c'était se bloquer là-dessus. Et donc, je peux rester des heures sur Google Earth.

11:47 Et maintenant, tu peux l'avoir dans ton navigateur sans rien installer. Et c'est d'une efficacité à toute épreuve. Tu as des suivis aussi sur des cartes des ouragans dans le monde. C'est fait en web assembly. Donc ça, c'est vraiment, en fait, c'est amener de la puissance de manière le plus standardisée possible au navigateur, de faire que ça soit safe. Oisem, dans le navigateur, ne peut pas faire plus que ce que le navigateur a le droit de faire. Donc, globalement, tu peux… Tu peux exécuter n'importe quel programme OASM dans ton navigateur, tu ne risques pas grand-chose, sauf si quelqu'un a fait une boucle infinie, ça va le surcharger, c'est tout. Et notre avantage, c'est que c'est polyglotte, donc ça peut intéresser effectivement plus de personnes. Il y a un truc sur lequel j'ai envie de rebondir là, tu as parlé de performance Wazem, mais ça me rappelle une anecdote que j'ai eue avec une boîte. Il ne faut pas se dire qu'en clair, s'il y a des problèmes de perf en JS, il ne faut pas commencer à se dire je vais tout réécrire en Wazem.

12:53 Et je ne vais plus avoir de problème de perf. Parce qu'en fait, c'est faux. Et j'ai une boîte avec qui j'ai discuté qui m'avait dit, on a fait ça, on a loué. Genre six mois pour réécrire tout un truc en Wasm et tout. Et en fait, le souci avec Wasm, qui n'est pas un souci, mais en fait, à partir du moment où on doit quand même beaucoup communiquer entre le WebAssembly et le JavaScript, faire beaucoup d'aller-retour, ça va être ultra coûteux en performance parce que Wasm, il n'a que 5 types scalaires, je pense. Et donc, toutes les structures qu'on a en JavaScript ou les trucs un peu plus avancés, si on les passe directement à WebAssembly pour discuter avec les fonctions WebAssembly, en fait, ça va être coûteux parce qu'on va devoir à chaque fois tout... Comme si on le sérialisait, tout transformer. Après, heureusement, dans V8, c'est quand même assez optimisé, mais ça a quand même un coût. Donc, si on commence à faire beaucoup d'aller-retour comme ça... L'avantage dans le navigateur, c'est que les outils existants, la chaîne de build existante, on sait, c'est plus plus, first, go.

13:55 Probablement d'autres, mais c'est celles qui sont plus avancées, elles fournissent toute la mécanique qui permet cette sérialisation des sérialisations. Donc, faire du WASM dans le navigateur, ça paraît super facile. Passer une string à une fonction, de base, tu as l'impression que c'est facile. Et en fait, non. Parce qu'à la base, comme disait Benjamin, Je ne me rappelle jamais le nombre de types, mais globalement, tu ne peux passer que des chiffres à une fonction. Autant que tu veux, elle ne peut te retourner qu'une seule valeur et ce sera un chiffre. Et donc, si tu veux faire un hello world en passant ton nom dedans, c'est juste… En fait, pas simple. Tu ne le vois pas parce que les chaînes d'outils le font. Alors qu'en Wazir, par contre, il faut que tu te fasses un peu à la main des fois. Et du coup, si tu passes des chiffres, les chiffres que tu vas passer, ça va être une adresse dans la mémoire partagée avec le fichier WASM. Et ton navigateur, ou la VM JavaScript, plus la taille de ce que tu veux lui passer, Après, tu vas avoir l'API.

15:00 L'iWazen qui te permet d'aller copier ça en mémoire, tu appelles la fonction. Elle sait que tu lui passes une adresse en mémoire et une taille, elle va aller le chercher. Puis après, il va falloir que tu lui renvoies une chaîne. Donc, ça veut dire qu'il faut que tu lui renvoies une taille et une position, sauf que tu n'as qu'une valeur pour le faire. Et c'est là où j'ai commencé à bloquer ce que tu veux. Moi, j'avais fait une école de commerce, maintenant je fais de l'informatique. Donc, quand on m'a dit, tu verras, ce n'est pas dur, il faut faire du… du calcul de bits, je suis passé un petit peu en mode blocage. Mais j'ai enfin compris comment le faire. Mais voilà. Il y a une autre question que j'ai envie de vous poser à tous les deux. On imagine bien cette notion d'environnement sandboxé dans le navigateur. On se rend compte de plus en plus fréquemment que l'on retrouve des applications et des services qui vivent en dehors du navigateur et qu'on va retrouver, par exemple, comme point d'exécution dans des faces ou autres.

16:03 Et tout à l'heure, Philippe, tu as parlé de Wasm, tu as parlé de Wazi. Est-ce que ce n'est pas le bon moment pour pouvoir essayer un petit peu de repositionner qui sont les différents acteurs de la chaîne? Quelle est la relation entre Wazi, Wasm? Est-ce que les contraintes d'exécution qu'on va avoir dans le navigateur ou protection, ça dépend comment on se place. Quand on va dans un monde d'exécution en dehors du navigateur, qu'est-ce que ça change un petit peu tout ça? Tu veux que je commence ? Vas-y. Benjamin, tu me coupes si je dis une bêtise. Les gens, ils ont trouvé ça super sympa, le site de WebAssembly dans le navigateur. Ils ont fait des trucs de fou. Le concept de la sécurité, de la portabilité, puis de l'efficacité aussi, c'est surtout ça qui est intéressant. Ils ont vachement intéressé. Ils se sont dit... Alors, on réinvente un peu la roue. On pouvait faire des trucs un peu en flash ou avec des applets il y a quelques années. Et puis là, on recommence de notre façon. Ils se sont dit, on veut pareil en dehors du navigateur. On veut pouvoir exécuter des modules Wazem.

17:07 Le fichier WASM, il faut le voir comme un fichier JAR avec Java, par exemple. Et tu as un runtime qui est porté par la VM JavaScript. Et en dehors du navigateur, il y a des gens qui ont commencé à créer. Il y a une spec d'abord qui a été créée, qui s'appelle WASI, pour WebAssembly System Interface. Et il y a quelques boîtes qui ont créé des runtimes qui suivent la spec. Donc, ça veut dire qu'avec ce runtime-là, tu vas pouvoir exécuter un fichier WASM qui respecte l'aspect WASI aussi. Et donc, tu as par exemple WASM Edge, WASM Time, WASM MER, et d'autres, ou à zéro aussi, et encore c'est un cas particulier, qui font ces runtimes-là, et tu peux faire, comme tu fais un Java, et tu exécutes quelque chose, tu pourras faire un Wasmer, le nom de ton fichier Wasmer, et l'exécuter. Et déjà, tu peux faire une CLA. Après, les gens… On s'en dit, mais ça serait bien si on pouvait avoir, nous, nos applications qui exécutent ces fichiers OASL.

18:08 Donc, les fournisseurs de runtime fournissent aussi un SDK qui permet d'appeler le runtime ou la VM au voisin à partir de ton application. Donc, ce qui veut dire que tu vas pouvoir fonctionner en mode plugin à partir d'une application Java, d'une application Go, des choses comme ça. C'est là où on revient sur la problématique dont je parlais tout à l'heure, enfin dont on parlait tout à l'heure, sur le fait que tu ne peux passer que des chiffres et récupérer que des chiffres, que des nombres. Et ça, cette mécanique-là, il va falloir que tu la codes. Donc après, les runtimes, tu as d'autres, on va dire, tu as des frameworks maintenant qui arrivent en fait et qui te proposent la mécanique pour faire ça simplement. Donc, si tu veux passer une string à ta fonction, ça va devenir facile. L'avantage des runtime et de leur SDK, c'est que tu peux créer aussi, ça c'est spécifique à Wazi, c'est pour justement le système interface, tu peux créer ce qu'on appelle des host functions.

19:14 C'est-à-dire que ton application host, tu vas créer, je ne sais pas, une… une fonction qui se connecte à du SQL Server. Et ton module OASM va pouvoir l'importer. et l'utiliser. Alors, comme pour la remarque de Benjamin tout à l'heure sur le fait que les fichiers WASM discutent avec le navigateur et que tu perds du temps, si ta fonction hot, enfin si ton hot n'est pas super rapide, Ton fichier WASM va ralentir quand il fera les appels à la fonction. Donc, il faut y penser aussi. Il n'y a pas de gestion asynchrone en WASM. Non, non. Ça peut vite être chiant. Pardon? Je dis, quand tu as... Il suffit des appels comme ça à de l'externe. Il faut savoir qu'il n'y a pas de gestion asynchrone dans Oisem. Ça va venir, mais c'est encore là. Par contre, du moment, et je pense que c'est un sujet important, on parlait de standardisation et de portabilité, du moment où tu commences à offrir tes propres fonctions hot, la portabilité, elle disparaît.

20:24 C'est-à-dire que ton fichier WASM, il va falloir qu'il s'adapte à la fonction ROT et tu ne pourras pas l'exécuter avec un autre ROT. J'ai des questions qui m'arrivent autour de la thématique, notamment de l'orchestration, mais je me les garde sous le coude. Avant d'aller explorer ça, j'avais une question pour toi, Benjamin. La sécurité paraît être une des caractéristiques un petit peu à part autour de WebAssembly. Du coup, quels en sont les principes? Comment elle est assurée? Je sais que tu as pas mal gratté ce sujet-là au niveau compilation plutôt bas niveau. Si tu veux nous expliquer et nous partager un petit peu cette partie-là, je pense que ça pourrait être vraiment intéressant. Oui, en clair, dans l'aspect Wazem, tu n'as rien qui te permet de faire des appels à des ayos, en réalité, dans l'aspect, dans le langage. Oui, parce que c'est un assembly, en fait, derrière.

21:28 Et du coup, ce qui est prêt... Par exemple, si tu commences à vouloir faire des functions as a service comme Lambda, par exemple, ou même dans la blockchain, les smart contracts, tu vas exécuter du code qui ne t'appartient pas sur ta machine, enfin sur des machines qui t'appartiennent, mais le code ne t'appartient pas. Et donc, tu n'as pas envie que... Les gens puissent commencer à aller voir dans le file system ou aller faire des appels réseau n'importe où, des choses comme ça. Et du coup, en fait, la spec de Wasm fait que les runtimes, parce qu'en fait, les runtimes, ils se développent autour de la spec qui est une spec officielle avec« Ah, j'ai telle instruction, qu'est-ce que je dois faire à ce moment-là? » Et en fait, les runtimes, sont censés respecter cette FEC. Et du coup, par défaut, tu n'as accès à rien, pas d'IO. Donc, ça veut dire que si tu fais un... Quand on fait du reste un print ou un console log, par exemple, ça ne sera pas logué par défaut.

22:31 Sans intégrer ce qu'on appelle Wazi, qui est en fait un autre genre de spec au-dessus de Wazen. Et du coup, ça te permet d'avoir un environnement ultra sandboxé. Et quand tu fais du function as a service, tu peux très bien dire, quand il y a un appel réseau, ça c'est un peu le rôle de Wazzy, c'est d'ouvrir la sandbox aux I.O. Aux appels I.O., quand tu fais un appel vers une I.O., ça va passer par ce que Philippe disait, cette host function qui est au niveau du runtime quand c'est oisille et on peut en faire nous-mêmes. Du coup, ça permet de contrôler ce qui se passe dans la boîte. Tout est bien fermé dans la boîte. Normalement, on n'a accès à rien parce que de toute façon, dans l'aspect et dans le langage, dans ce qu'on va compiler en WebAssembly avec l'Assemblée, rien ne nous permet dans le fichier d'accéder à des I.O. Donc en fait, on est assez safe à ce niveau-là. On est capable de contrôler ce qui va être fait au niveau du programme.

23:34 Et ça, c'est plutôt cool, je trouve. D'accord. Si je me tourne du côté des questions sur la partie Q&A, il y a deux questions qui ont été posées, une première par Samir et une deuxième par Yann. Regardez celle de Samir et qui est peut-être dans la prolongation de ce que tu viens d'évoquer, Benjamin, sur la partie sécurité. Philippe, bien sûr, n'hésite pas à réagir. Du coup, quick de la partie performance, on a tout à l'heure, quand je faisais l'intro, je disais qu'il y avait trois caractéristiques qui étaient clés autour d'Oisem, la sécurité, la portabilité et la perf. Du coup, là, la question qui est posée par Samir, c'est aujourd'hui, comment est-ce qu'on peut évaluer la perf? Autour de WebAssembly. Je ne sais pas, messieurs, si vous avez des... Je vais commencer, je pense que Philippe pourra suivre, parce que moi je n'ai pas énormément d'infos sur la paire, parce que ce n'était pas, dans mes utilisations, ce n'était pas mon objectif premier de faire du voisin. pour faire de la perf, c'est pas pour ça, c'était plus pour l'aspect universel et pouvoir utiliser cette spec un peu de façon transportable.

24:41 Et du coup, la perf n'était pas forcément le premier cas. Après, quand j'ai dû mesurer la perf, par exemple, quand j'utilisais ce que j'appelle un WASM en mode FFI, donc j'avais un bootcode qui était dev en Rust et je voulais le réutiliser dans un autre langage. Je faisais du tracing ou des métriques et j'étais capable. de voir depuis mon appli de base combien de temps ça prenait pour appeler ce code-là. Je n'avais pas de problème à ce niveau-là. Mais du coup, je n'ai pas énormément d'infos autour de ça, mais il y a plein de... Il y a plein d'analyses de perfs sur Internet et d'explications sur le fait que, déjà, dans le navigateur, le WASM soit plus rapide que JavaScript. Ça s'explique assez facilement. C'est parce que déjà, quand tu as du WASM, c'était un peu comme disait Philippe, l'idée d'SMGS, tu as du WASM, il est compilé. Donc, c'est déjà un langage qui est compilé. Donc, il y a déjà eu des passes d'optimisation faites par le compilateur. C'est une spec qui est assez… En fait, il n'y a pas énormément de mots-clés, de keywords et tout ça.

25:45 Donc, c'est assez rapide à interpréter. Et il n'y a pas de garbage collector, donc on n'a pas un garbage collector qui va nous prendre de la perf comme on pourrait avoir en JS par exemple. Donc ça, c'est aussi des points d'explication autour de pourquoi la perf. Sur la partie perf, en fait, je cherchais, je l'ai retrouvé, il y a quelqu'un qui a écrit un benchmark que je trouve assez intéressant et qu'il actualise assez régulièrement. C'est quelqu'un qui s'appelle Franck Denis, je vais vous partager. Je vais vous partager dans le navigateur le lien. Il utilise une librairie qui s'appelle Ipsodium et il teste à peu près tous les runtime wasm qui existent. Le protocole de test qu'il partage, je trouve, est assez intéressant, en tout cas pour toutes les personnes qui se posent des questions sur comment aller mesurer ou comment évaluer de la perf autour de Wasm. Je trouve que les travaux qu'il a proposés sont un bon point d'entrée pour pouvoir avancer.

26:54 Petite remarque sur la perf, avant qu'on passe à un autre sujet. J'ai commencé justement à travailler le sujet, parce qu'il y a des moments où il va falloir que, pour certaines présentations, je donne quelques exemples. Je crois qu'il ne faut pas focaliser en tout cas sur la vitesse, mais plus sur l'efficacité de WebAssembly, c'est-à-dire son poids et la ressource consommée. De toute façon, ça aura un impact sur les perfs de l'application en général. On parlait de cas d'usage. En plus, ça tombe bien, je vois qu'il y a quelqu'un qui pose une question sur les cas d'usage. On parlait de Function as a Service. Wazem, c'est tout petit. Tu peux créer une fonction hot, un petit exécutable en Go ou dans un autre langage qui va être tout petit et qui va le servir comme un… qui va le loader et l'appeler et le servir comme un microservice. Il est vraiment tout petit. Tu vas pouvoir le mettre dans une image Docker from scratch. Donc, ton image, elle va peser… 20 mégs à tout casser contre les 100, 200, voire quelques gigas que tu peux avoir d'habitude.

27:59 Et du coup, quand tu vas avoir… vouloir déployer ton application dans du cube, déjà ça va se faire vite parce que l'image est petite. Et quand tu vas la scaler et que tu dis je veux 30 potes d'un coup, ça va se faire super rapidement parce que c'est petit. Et là, tu gagnes en efficacité de manière indirecte. Après, pour calculer la rapidité, l'efficacité comme la personne a fait les benchmarks, il faut que tu colles des choses dans… dans ton code pour faire ça finalement pour dire je lance mon timer mon chrono au début et je l'arrête à la fin et tu fais des comparaisons et pareil avec l'histoire des host functions ça va toujours générer des problèmes moi je vois j'ai un module wasen qui est fait avec le framework Extisum, et je le fais tourner avec du Java, avec du Node, avec du Go, et les écarts sont juste hallucinants parce que l'appel de host function n'est pas le même. Une host function faite en Node, elle est lente, mais ça marche par contre. Philippe, tant qu'on est sur les exemples, j'avais un exemple que je trouvais très parlant, que je viens de retrouver, je vais vous partager le lien.

29:05 L'histoire, c'est une société aux Pays-Bas qui est spécialisée dans des images de photos d'art en très haute qualité. Et en fait, ce qu'ils avaient avant, ils avaient une solution cloud web centralisée où les personnes, finalement, avaient une interaction entre leur navigateur et le service. centralisé. Là, ce qu'ils ont fait, c'est qu'ils ont découpé leur service en fonctions, comme tu l'as indiqué, et ils ont déployé les fonctions de Zoom au niveau des CDN, puisqu'ils travaillent avec une solution de CDN qui supporte l'exécution de Wasm. Et du coup, ce qui est très intéressant, c'est que l'effet de Zoom va se jouer au niveau des CDN et non plus au niveau central. Et le gain en termes de perf sur le grossissement et les zooms sur les photos, On va jusqu'à voir la trame des tableaux derrière. C'est vraiment très impressionnant.

30:05 Et ce qu'ils expliquent, c'est qu'ils n'auraient pas pu le faire autrement qu'avec une approche à la Wazem. Je vous mets dans le chat le lien vers cette histoire que je trouve intéressante pour pouvoir représenter un autre cas concret. En termes d'utilisation. Pendant que tu partages le lien, en termes d'utilisation, il y a la notion de plugin qui est très vaste, parce que tu peux utiliser pour faire du functionality service ou rajouter des plugins dans ton application. Tu as ce qu'on appelle Zelligi, qui est comme un Temux dans Linux. Tu peux lui rajouter des plugins en Wazem. Mais tu peux faire aussi des user-defined functions dans des bases de données. Tu as SilaDB, je crois, qui fait ça. Il doit avoir un POC bêta pour PostgresQL. Donc, ça permet de faire ça. Tu peux avoir aussi des filtres dans les proxys. Un Envoy Proxy, par exemple, qui te permet de faire des filtres. Avant, c'était en Lua, je crois.

31:06 Lua et C++, et maintenant, tu peux le faire en Wasm. C'est encore en bêta, il me semble. Et puis après, ce sera des dérivés de cas d'usage, parce que tu peux faire des webhooks. Super facilement. Tu peux embarquer un interprèteur JavaScript dans un module OASM et du coup, tu vas pouvoir dire à tes clients, fournissez-moi des fonctions JavaScript. Moi, j'ai la garantie qu'elles sont sans problème. que c'est qu'elles s'exécutent dans mon module OASM. Donc, on revient sur la sécurité et je vous les lance comme ça. Donc là, tu perds en rapidité. Mais par contre, c'est Shopify, je crois, qui fait ça pour ses clients. Il y a un projet aussi marrant, c'est Crosslet, qui est développé par Azure en soi. Enfin, c'est la R&D de Azure. Crosslet, c'est un truc qui permet, dans Kubernetes, au lieu de lancer un conteneur Docker ou quoi, ça lance un module Wasm. C'est là où on repère en standardisation. Parce que les gars qui ont fait Crustlet, je crois que c'est les anciens de...

32:11 De EUS. De EUS Lab, oui. Et qui sont maintenant chez... C'est ceux qui ont créé Fermion. Et... Et je crois que le projet est un peu moins utilisé parce que tu as ceux de Wasam Edge qui ont fait un deal avec Docker, qui ont un POC où en fait, c'est Docker qui fournit le runtime. Pour l'instant, au hasard, ils ne font ni que du Wasam Edge comme runtime. Et du coup, ils chargent ton fichier Wasam. Mais normalement, avec Wazen, tu ne peux rien faire, sauf ce que te permet le runtime qui suit la stack. Comme la stack n'est pas beaucoup évoluée, tu ne peux pas faire grand-chose. Et ce qu'a fait Wazen, c'est qu'ils ont implémenté leur propre version de socket. Donc, du coup, tu peux écrire un serveur HTTP. dans le fichier Wazem au lieu de l'écrire dans l'autre. Et ils ont une super démo qui te permet de faire un micro-service en Rust, d'attaquer du MySQL. Mais tu ne peux pas l'utiliser avec les autres runtime parce qu'ils n'implémentent pas la socket ou ils le font de manière différente.

33:19 Il y a la même chose dans Crosslet, ils ont leur propre implème pour gérer les appels réseau. C'est très dépendant. Du coup, c'est joli, c'est sympa comme truc. Il y a encore un autre truc avec ContainerD, je crois qu'il est sorti il n'y a pas longtemps dessus. Mais pour l'instant, mon sentiment est plus que tu vas plus y gagner en faisant ton propre hot qui embarque en runtime et qui exécute ton fichier WASM. Et le mettre dans une image Docker la plus petite possible. Au moins, tu sais que ce que tu fais n'utilise que l'aspect quasi du runtime et le reste, c'est toi qui le fournis. Mais c'est mon avis très perso. Non, en clair, moi, je trouve que Wasm, c'est super. Quand tu dois dé-sandboxer le truc, là par exemple, juste faire un appel réseau, ça devient l'enfer parce qu'en fait, il n'y a rien de stable. Et pour juste faire un bref résumé, Wazi, là on parle de Wazi depuis le début, mais on n'a pas vraiment bien expliqué ce que c'était. En clair, Wazi, ça va permettre de dé-sandboxer Wazen. C'est genre un genre de ABI, une spec qui dit, ok, quand tu vas essayer de faire dans ton langage un file descriptor open ou des choses comme ça, ça va appeler tel external.

34:30 fonction, donc une external function, c'est ce que Philippe disait, ça va faire suivre au runtime, ok j'ai cet appel de fonction là, je ne connais pas ce que c'est, c'est le runtime qui va s'en occuper. Et donc normalement, les runtimes implémentent ces prototypes de fonctions parce qu'ils savent que c'est dans l'aspect Wazzy. Et en fait, le problème de l'aspect Wazzy, c'est qu'ils ont décrit l'aspect pour faire, je pense, des ouvertures de fichiers, des écritures et tout ça. Mais pas vraiment des appels réseau, HTTP et tout ça. Et donc, en fait, chacun, il y a un truc qui s'appelle Wazzy, expérimental HTTP, mais je ne sais pas où ça en est. Il y a toujours expérimental dedans et j'ai l'impression que pas beaucoup de gens l'utilisent. Chacun crée sa propre surcouche HTTP ou des choses comme ça et du coup, ça devient l'enfer. Alors, Wazam Edge a décidé de se calquer sur ce que faisait Wazam Time. Normalement, ils auront la même implème de socket, mais est-ce qu'elle suit l'aspect? Je ne sais pas. Donc, ça évolue, mais doucement. C'est pour ça que je pense qu'il vaut mieux fournir ses propres functions pour ce qui n'est pas implémenté.

35:32 Et je voulais dire un truc par rapport à ce que tu as dit, j'ai oublié, ça m'est sorti de l'esprit. Ça ne devait pas être important. Il y a un des camarades de Benjamin qui a une question dans le chat. Y a-t-il un intérêt à Wazem hors navigateur? Après, on a presque répondu à tout. Oui, c'est un peu… Moi, ça a déjà été un peu abordé. Moi, messieurs, j'aimerais bien qu'on bascule dans une autre partie de notre échange. L'idée et la philosophie de Tech.Rocks, c'est d'essayer toujours d'apporter un peu de matière pour permettre à l'audience de pouvoir repartir avec quelque chose dans le sens où ils peuvent essayer. Moi, les questions que j'ai envie de vous poser, concrètement, c'est quoi les ingrédients de la chaîne? Si on se calque dans une stack de dev normale, quel langage, quel framework, qu'est-ce que j'ai besoin dans ma chaîne pour pouvoir compiler? Quand je vais vouloir distribuer, Qu'est-ce que j'utilise comme repo de distribution ?

36:34 Au niveau de mes run time, vous en avez un peu parlé, mais c'est peut-être intéressant de les rebalayer. Je sais également qu'on a des espèces de plateformes as a service, de passes d'exécution ou as them qui amènent des services de haut niveau. J'aimerais bien qu'on passe un petit moment pour pouvoir amener un peu de matière à notre audience en se disant, tiens, moi, si j'ai envie de démarrer ou d'essayer de faire mon Hello World, et on a bien compris, Philippe, que si tu voulais passer ton prénom après le Hello World, il allait falloir donner des chiffres. J'aimerais bien qu'on regarde un petit peu cette partie chaîne et pipeline de production parce que finalement, comment ça se fabrique? À la fin, une fois que tu as compris le paysage oisif, parce que le paysage oisif, il est simple, finalement, ça marche dans le navigateur et c'est plutôt production ready, je dirais. Tu vas fonctionner finalement comme tu fonctionnes avec tes outils actuels. Mais si tu prends les run time, en général, c'est un… Attends, attends, attends, Philippe, avant de démarrer, mais quand tu commences à coder, tu codes en quoi? Aujourd'hui, je veux faire du WASM, je code en quoi?

37:37 C, C++, Rust, Go, sans script, mais juste pour le Wazem, parce qu'il y a eu un drama sur la partie Wazie et la bike de Diagans ne leur a pas répondu ce qu'ils voulaient, donc ils ont décidé qu'ils ne feraient plus de Wazie. Du Swift, tu as dû le dire, du Zig, du… Je crois avoir vu du Python aussi. Alors, c'est du Python qui est embarqué dans du Wasm. Donc, je soupçonne que c'est une espèce de VM Rust codé en Wasm qui exécute du Python, des choses comme ça. Je ne suis pas sûr, je n'ai pas encore creusé le sujet. Un de mes collègues, Martin, qui est là d'ailleurs, m'a dit hier que dans Kotlin, c'est sorti en expérimental la semaine dernière. Oui, il y a Sébastien Deleuze qui travaille beaucoup sur le sujet, effectivement. Et on peut builder en Wasm. Par contre, il n'y a pas Wasm pour Kotlin encore. Oui, non, je ne pense pas. Normalement, c'est que navigateur. Il faut être quand même honnête, il y a des langages avec lesquels ça va être plus agréable qu'avec d'autres de faire du Madam.

38:38 Le plus adapté, je pense que c'est Rust. En plus, à l'exécution, il est quand même plus rapide. Je ne voulais pas être celui qui le dise. Non, non, mais je te dis, après moi, je suis plus à l'aise avec du Go qu'avec du Rust, mais je ne désespère pas d'y arriver. Et encore qu'avec Go, c'est particulier parce qu'il vaut mieux utiliser le compilot TinyGo qui build des tout petits binaires, contrairement à Go qui fait des trucs énormes et dont ton navigateur, ça va être un peu difficile. Enfin, ça va être long à charger et sur la partie wasi, Go, ce n'est pas encore le faire. Je pense que TinyGo, c'est parce que déjà, il a un plus petit runtime Go, je pense. Oui, c'est pour les microprocesses. Comme le garbage collector, ce n'est pas supporté dans Wasm, il faut qu'ils mettent ce runtime Go avec ce garbage collector quelque part dans le Wasm. Je pense que du coup, TinyGo, il permet d'avoir un runtime plus petit, plus light. On a compris qu'on avait globalement quand même pas mal de langage sous le coude, même si vous avez un consensus autour de celui avec lequel ça paraît le plus évident à utiliser.

39:45 Ok, comment je compile? Avec, en fait, chaque langage qui sait cibler du WASM te fournisse à tout le chien pour compiler. Ok. En was it? Donc, Ango ou TinyGo, c'est... Embarqué dans le compilot. En Rust, c'est WasmPack, si je ne dis pas de... Non, non, non, en Rust, c'est embarqué aussi dans le compilateur avec Cargo. C'est considéré comme une target, en fait, comme si c'était du X86. Ah oui, exact. En fait, WasmPack, c'est pour compiler, ça va compiler ton... Ça va faire tout le packaging pour faire du JS après derrière, pour ça te créer un fichier JS et ça l'inclut. Il fait toute la mécanique qui serait chiante à faire en fait, Oisem Pack. Exact, autant pour moi. Quand tu veux faire du front. Ok, donc là, on a notre langage, on a compilé, on a un point Wasm. Comment ça se distribue? Tu vois, codement un container, tu vas le mettre dans un container hub de ton choix.

40:49 Maintenant, avec la norme aussi à enregistrer, tu peux mettre ton… Alors, je crois que dans Docker, ce n'est pas encore possible, mais ça ne va pas tarder. Uh, Mais tu peux très bien utiliser, la générique registrée de GitLab, ça marchera, mais tu peux utiliser, c'est Wasmer, je pense que c'est Wasmer. WAPM. Pardon? WAPM, c'est pas ça que tu veux? Ah oui, tu as raison. Donc de chez Wasmer, qui est une Wasm enregistrée. Tu as Arbor maintenant qui est compatible et qui te permet de… Mais ça ne fait pas longtemps, je crois. Qui te permet de… de servir du fichier Wazel. Ou sinon, tu fais juste un... GitHub aussi, normalement, te permet de le faire. Ok, si on continue toujours dans notre chaîne, Philippe, je sais qu'on a eu l'occasion d'en discuter ensemble quelques fois, on voit arriver des plateformes d'exécution de plus haut niveau que le runtime au travers de passes, il y en a actuellement sur le marché 3-4, voilà.

41:57 Qu'est-ce que ce type, alors déjà, quelles sont ces plateformes et qu'est-ce qu'elles apportent dans l'expérience de dev et dans le service que tu rends en fait? Quand tu parles de plateforme, tu pensais par exemple à Wazem Cloud de Cosmonic? Je pensais exactement à Cosmonic. Tu as fait un énorme bond entre la partie one time pour aller à la plateforme. Entre temps, il y a des frameworks qui te permettent de te simplifier la vie justement si tu veux passer par exemple un Toto à un Elward. C'est important d'en parler parce qu'en général, ces frameworks-là donnent lieu aussi à d'autres frameworks. J'appelle ça application framework. Et WasmCloud en fait un, justement, qu'ils ont dû appeler WasmCloud Host Run Time, si je ne dis pas de bêtises, ou Fermion, c'est Spin. Donc, eux, c'est des mini-serveurs d'applications. Et après que tu peux exécuter chez toi ou sur tes propres machines. Et après, ils vont fournir effectivement aussi des plateformes pour héberger ça.

42:59 Donc, ils utilisent leurs propres. Le framework et tu le fournis as a service. Donc, les plus en avance, je pense que c'était les premiers dans ce domaine-là, en tout cas, fournir quelque chose de plateforme ready, c'est WasmCloud de Cosmonic. Alors, leur système de fonctionnement pour leur framework est plus à base d'acteurs que de microservices, si je ne dis pas de bêtises. Et ça fonctionne sur du NATS pour le protocole de communication. Je n'ai pas encore testé vraiment beaucoup, mais sur le marché, je pense que c'est les plus crédibles pour le moment parce qu'ils étaient là avant tout le monde et qu'en plus, les différents créateurs ont un background plutôt solide. Tant techniquement que financièrement, des impressions. Ensuite, il y a une petite boîte canadienne d'Ottawa qui s'appelle Suborbital qui fait un outil qui s'appelle Extension Engine. C'est du fonctionnalité de service.

44:02 Framework, tu peux exécuter toi-même. Fermion fournit aussi une plateforme à la fois as a service ou que tu peux installer chez toi, ce qui est le cas pour Wazam Cloud aussi d'ailleurs. Fermion est pas mal en avance. Eux, ils ont commencé par faire leur petit framework spin. Ils ont démontré qu'avec, ils pouvaient faire un CMS complet qu'ils utilisent. Et une fois qu'ils ont eu ce proof of concept, ils ont mis en place Fermion Cloud. C'est la partie SAS. Et Fermion Platform, c'est la même chose, mais que vous pouvez installer chez vous. Il y en a probablement d'autres, mais je ne les connais pas. S'il y a... Alors, est-ce que c'est avec le cube d'Azur? Microsoft travaille énormément sur WebAssembly. Oui, ils ont Hippo, ils ont plein de trucs. Oui, alors Hippo, pareil, je crois que c'est ceux qui sont chez Fermion maintenant qui avaient fait ça. Mais il me semble qu'ils ont un système... Je ne sais plus si c'est du Function as a Service ou du Cube, parce que je ne fais plus de .NET depuis des années, mais il y a un SDK .NET pour Wazzy.

45:12 C'est encore… Parce qu'avant, ils faisaient Blazor, c'était un truc un peu full stack. Et là, ils font vraiment quelque chose d'orienté Wazzy qui marche du feu de Dieu. J'ai vu une démo à QCon Valencia l'année dernière. On sent, ils n'en parlent pas énormément. Mais ils doivent faire partie techniquement des acteurs qui ont le plus d'avance sur la partie compilot et debugging. Ok. On est en train de se rapprocher gentiment de la fin de notre session. Il reste 10 minutes et ça serait bien de voir si on a des questions complémentaires depuis l'audience pour les traités. Moi, avant peut-être d'accueillir des questions tiers, j'ai envie de vous poser la même question à tous les deux. On a vraiment vu en 2022 un mouvement extrêmement fort. Qu'est-ce qu'on va avoir en 2023 et de quoi on a besoin pour avoir cette confirmation et qu'on atteigne un seuil de maturité finalement, qui est le signal qu'attendent peut-être pas mal d'entreprises pour pouvoir passer le cas.

46:20 Pour vous, à quoi... Que peut-on attendre, Benjamin, si tu veux commencer? Ce que j'aimerais avoir, mais après c'est un peu salé, mais c'est juste que... Des proposals au working room de Wasm, ils commencent à un peu l'endre des trucs, enfin un peu accepter et commencer à faire évoluer vraiment l'aspect dans le sens à ce que ça puisse être utilisable de façon moins... Moins instable au niveau back-end, par exemple avoir du Wazir pour du HTTP et que ce soit stable et que tout le monde utilise les mêmes prototypes et tout ça, ça serait vachement cool. Ce n'est pas grand-chose en soi, il faut juste qu'ils se mettent tous d'accord, après ça c'est compliqué, mais au moins ça, ça permettrait d'avoir un truc un peu plus universel. Ça, ça serait super. Au moins déjà pour cette année. Philippe? Moi, je pense qu'à mon avis, ce sera la spec qui va sortir le plus vite. Comme ça, l'année prochaine, vous pourrez me dire, Philippe, tu t'es trompé, ce n'est pas ça. Je n'ai plus le nom de la spec, mais globalement, ils avaient prévu de faire des types un peu plus évolués qu'uniquement des nombres.

47:26 Externally. Il y a 17 sur les strings, par exemple. Donc, normalement, il devrait avoir ça. Ce qui serait bien, mais alors la dernière fois que j'ai regardé sur GitHub, l'activité de l'aspect, c'était calme plat. C'était le debugging. Pour l'instant, on ne débug pas en réseau. Il faut que tu te codes une fonction de log, par exemple. Et après, tu te débrouilles comme ça. Et j'en donne une troisième qui peut-être sortira avant les titres. D'ailleurs, je pense que c'est la gestion des exceptions. Voilà. Mais moi, honnêtement, c'est celle des types qui me ferait le plus plaisir. Oui, mais External Ref, je pense que ça s'appelle, c'est External Ref dont tu parles. Et en fait, ça fait super longtemps qu'elle existe et j'ai l'impression que ça ne bouge pas. Oui, mais parce qu'en fait, il y a eu une nouvelle qui a changé de nom. Ok. Et c'est pour ça que je n'arrive plus à retrouver le… J'ai essayé de chercher pendant que tu parlais et je n'arrive plus à… Je n'arrive plus à retrouver le nom. Exceptional Garbage Collection. Je regarde un dernier truc. Non, je ne l'ai pas, parce qu'en fait, c'était à partir d'une animation qu'il y avait sur Twitter.

48:29 Um, Très bien. Avant de passer aux questions, j'avais une information à vous partager. En fait, là, sur le mois de février, avec l'équipe Tech.Rocks, on voulait vraiment marquer le coup autour de WebAssembly. Donc, on a eu ce jour-là ce meet-up avec Benjamin et avec Philippe. Il se trouve qu'il y a un peu plus d'une semaine, j'ai eu le plaisir d'interviewer Liam Randall, qui est le CEO de Cosmonic. On a 35 minutes de podcast préparé, où j'en ai profité pour interviewer l'IOM sur sa compréhension de WebAssembly, comment lui le voit évoluer, comment il le voit arriver également à maturité, et pour quel type de business, comment est-ce qu'il voit son environnement de plateforme évoluer. Donc honnêtement, ça a été un moment extrêmement dense et un enjeu de le faire tenir dans 35 minutes. Et je pense que ce podcast sera diffusé bien sûr via le site.

49:30 Tech.Rocks et les canaux habituels, là, je pense que sous deux semaines maximum, ils devraient être en ligne. Au niveau questions, je ne sais pas si on en a d'autres qui sont arrivées. Quand on va dans la partie Q&A, il y a la question sur les cas d'usage. Je ne sais pas si certains d'entre eux… Enfin, voilà, on en a déjà couvert pas mal. Moi, j'en ai peut-être une, peut-être pour... pouvoir lancer, alors le truc ça va être de le faire de manière extrêmement courte. Vous en avez un peu parlé, mais comment on gère la mémoire? Benjamin, on a parlé un peu de garbage collector, moi je suis curieux de comprendre un petit peu ce qu'il y a derrière ou justement ce qu'il n'y a pas en fait. En clair, il n'y a pas de garbage collector et la gestion mémoire est super simple en soi parce que c'est stack-based. Ça veut dire que ce n'est pas comme un assembly où il y a des registres, où on doit mettre les valeurs dans des registres et on va additionner les registres entre eux.

50:35 Tout passe par une stack partagée globale. Par exemple, si on veut faire 1 plus 2, on doit mettre 1 dans la stack, on push 1 dans la stack, on push 2 dans la stack. On appelle juste l'instruction add. Et en fait l'instruction add ne prend pas de paramètres comme on pourrait avoir par exemple avec une version registre ou si c'était une version avec registre on aurait eu add le registre dans lequel on met la réponse ensuite les deux registres à additionner ensemble là c'est juste add parce que tout passe par la stack et donc il va faire 1 plus 2 il va popper les deux éléments de la stack il va les additionner ensemble et il va mettre la réponse directement dans la stack donc il va repoucher la réponse dans la stack donc 3 donc on aura à la fin de cette addition juste 3 dans la stack qui est empilée Est-ce que ça a été clair ou pas? C'est plus facile de faire avec une image. Du coup, quand on est informaticien, gestion comme moi, ça a des implications auxquelles tu ne penses pas forcément.

51:36 Si par exemple, tu fais un service HTTP qui va appeler ton module OASM en lui passant des informations à la fonction, au bout d'un moment, tu vas faire péter la mémoire parce qu'en fait, c'est le module OASM partage la mémoire avec l'autre. Donc en fait, il faut que tu penses à un instancier. Un nouveau module à chaque fois pour éviter ça. Et moi, je m'étais fait avoir parce que je faisais en Node.js et que le modèle de Node.js fait qu'en fait, il traite les informations les unes après les autres et pas tout en même temps. Donc, je n'avais pas vu ça. Quand tu compiles en Wasm, il va analyser statiquement et te calculer plus ou moins la taille que la stack va avoir pour ce programme. Je ne sais pas si ça le fait dans tous les langages, mais en tout cas, on reste avec LVM. Il nous donne la taille plus ou moins de la stack. Il y a une dernière question, et je pense que ça sera avant de clôturer le meet-up. Peut-être vous faire sortir un tout petit peu de votre zone de confort. On était dans des choses qui étaient très techniques, et c'était l'esprit, le sens.

52:37 Il y a une question que je trouve intéressante sur le Q&A, qui est sur la valeur business et à quel point on est rapide. Moi, là où j'aimerais vous entendre, c'est une entreprise, quel que soit son secteur d'activité, ne va pas s'amuser à prendre du WebAssembly pour se faire plaisir. Elle va le faire parce que derrière, il y a un... intérêt et j'aimerais bien vous entendre quels sont les signaux ou quels sont les cas où vous vous diriez respectivement avec vos expériences, tiens là il faut absolument qu'on s'intéresse à WebAssembly parce que telle et telle et telle et telle propriété font que ça va nous amener de la valeur, de la différenciation, je ne sais pas, en tout cas, moi, c'est une question que j'ai envie de vous poser. Merci. Moi, dans mon cas, ça me rappelle une discussion que j'ai eue un jour en Espagne autour d'une sangria. Dans mon cas, c'est l'efficacité de Wazen qui aura un impact le plus sur la valeur business.

53:45 Alors, si on dit valeur business, je pensais plus… quelque chose relié à l'argent, à l'impact que ça peut avoir sur ton budget. Je suis d'accord qu'il ne faut pas réécrire complètement une application parce que les gens qui ont investi là-dedans, ça va leur faire bizarre, surtout si ça ne fait pas longtemps qu'ils l'ont écrite. Mais plus tes applications sont efficaces. Donc, quand je dis efficace, c'est moins de consommation de ressources, mémoire, CPU et tout ça. Plus ça sera efficace, moins ta facture cloud sera salée. Donc, des fois, moi, j'ai vu des cas, j'ai bossé pour une boîte qui faisait du pass. Certains de nos clients limitent. le nombre possible de VM en scale pour ne pas trop dépenser. Et il y a probablement des gens qui font la même chose sur… Enfin, s'il y a des gens qui le font, limiter le nombre de pods en scale sur quelque chose, des choses comme ça. Mais si tu divises par 10, 20, 30, voire plus la taille, de ton application, tu dépenseras moins d'argent pour un service équivalent.

54:56 Pour l'instant, c'est la seule piste que je vois. Très bien. Benjamin? Maman, de ton côté, est-ce que tu as une idée ? Ou est-ce qu'il y a quelque chose? Par exemple, dans mon ancienne boîte, c'était plutôt aussi lié à l'argent. Mais après, on parle business. Une question business. C'est qu'en fait, du coup, on avait des algos crypto déjà écrits en russe, dans un langage. Et on ne voulait pas devoir les réimplémenter pour d'autres langages par rapport à des besoins des clients ou ça, même juste pour le front. Du coup, c'était plutôt pratique d'avoir un truc portable qu'on ne doit pas réécrire et qu'on puisse mettre dans n'importe quel langage, sans trop de contraintes. Très bien. Surtout pour de l'algo où on ne fait pas d'IO, le boisem est plutôt pratique pour ça. Très bien. Il est 13h pile. On vient d'atteindre la fin de notre séance. 30 secondes chacun. Est-ce que vous avez un dernier message à passer ou quelque chose qui vous tient à cœur sur notre thématique du jour?

56:06 Je dirais, mettez les mains dedans, essayez, plongez-vous dedans, amusez-vous avec. Vous allez voir, vous n'allez pas forcément ressortir avec des mains très sèches ou propres, je ne sais pas comment le dire. Mais c'est toujours fun, on apprend des choses et on voit qu'il y a un réel... Intérêt à utiliser ça. Après, il faudra voir comment l'aspect évolue. Ça marche. J'ai à peu près le même message. Mais comment ça, poquer des choses? Parce que je suis intimement persuadé qu'à minima, sur la partie fonction as a service, qui n'est pas le monde entier du cloud, mais qui est quand même vachement utilisé, Donc, ça va être ça, les hooks, les trucs comme ça. Mais c'est pareil, ça a un réel intérêt. Au moins pour être prêt. La spec n'est pas cuite, vous allez faire des trucs pas cuits, mais le jour où ça accélère, au moins vous serez prêt. Très bien. Jetez un œil, on n'en a pas parlé, mais jetez un œil à WIT, qui est un truc qui permet de, en tout cas, ça fonctionne sur plusieurs langages, mais qui permet de faire ce que Philippe disait, de ne pas se palucher à devoir

57:12 avoir des pointeurs ou quand on veut passer une string, ça change automatiquement, ça crée les by-gen pour nous dans le langage qu'on veut, à partir d'une description, un SDL comme en protobuf par exemple, et du coup ça facilite grandement la vie. Très bien. Tu as dit que ça s'appelait comment? Parce que moi, je ne connaissais pas. WIT by NgenW. Ah, d'accord. Je ne savais pas que ça allait jusque-là. Ok, c'est plutôt pratique. Merci messieurs, vraiment un immense merci, c'était très riche et je pense qu'on aurait pu y rester encore bien plus longtemps. Peut-être qu'on va rappeler notre ami Noémie à nous rejoindre sur scène avant de clôturer et peut-être de rejoindre les salles. Noémie, est-ce que tu veux venir avec nous ou on sort directement? Dis-nous.