Comment introduire efficacement des langages de programmation à ramasse-miettes (GC) dans WebAssembly

• Un article sur une nouvelle manière d’appliquer efficacement des langages de programmation à ramasse-miettes (GC) à WebAssembly (Wasm)
• La proposition GC vise à prendre en charge les langages GC dans Wasm, ce qui est important en raison de leur popularité.
• L’article explore les détails techniques de la façon dont des langages GC comme Java, Kotlin, Dart, Python et C# peuvent être portés vers Wasm.
• Deux approches principales sont abordées : la méthode de portage « traditionnelle » et la méthode de portage WasmGC.
• La méthode de portage « traditionnelle » consiste à compiler l’implémentation existante du langage vers le produit minimum viable de WebAssembly (WasmMVP), lancé en 2017.
• La méthode de portage WasmGC consiste à compiler le langage vers les structures GC propres à Wasm, telles que définies dans la récente proposition GC.
• L’article examine les compromis techniques entre ces deux approches, en particulier en matière de taille et de vitesse.
• WasmGC présente plusieurs avantages majeurs, mais nécessite aussi de nouveaux travaux dans la toolchain et les machines virtuelles (VM).
• L’article explique également les travaux menés par l’équipe V8 dans ces domaines, y compris des chiffres de benchmark.
• Il conclut que WasmGC constitue une nouvelle manière prometteuse d’implémenter des langages GC dans WebAssembly et exprime l’espoir que les ports WasmGC deviennent une technique populaire en raison de leurs avantages.

[GN⁺]

Avis Hacker News

• Un article sur l’introduction de langages de programmation à ramasse-miettes dans WebAssembly (WASM)
• Les commentateurs se montrent enthousiastes à propos du potentiel de « taille de guêpe » de WASM, ainsi que de l’idée qu’un ramasse-miettes et N+M valent mieux que N×M
• Curiosité autour de l’existence de WASM vers la JVM, un commentateur dit en avoir trouvé un sur GitHub
• Le potentiel des threads WASM à offrir un véritable parallélisme, avec l’espoir que cela puisse résoudre efficacement les problèmes d’asynchronisme, de parallélisme et de ramasse-miettes
• Mention du tooling WASM de Julia, qui pourrait prendre en charge cette fonctionnalité, avec l’exemple de la compilation de solveurs d’EDO en WASM
• Comparaison avec le sentiment « wasm est le nouveau llvm », ainsi que le scepticisme de certains commentateurs qui se demandent quand une adoption plus large sera possible
• La sortie de cette fonctionnalité est jugée impressionnante, certains commentateurs ayant douté qu’elle puisse se concrétiser
• Inquiétudes concernant la complexité des navigateurs actuels et la courbe d’apprentissage abrupte liée à la création de son propre navigateur
• L’espoir d’un futur où un binaire wasm pourrait servir de point d’entrée à un site web, ce qui pourrait améliorer le temps de démarrage des applications web dynamiques
• Le nouveau support de wasm dans Kotlin est jugé intéressant, et une version expérimentale de Compose Multiplatform cible les navigateurs en utilisant WASM
• Un certain scepticisme face à la complexité accrue de WebAssembly avec l’introduction d’un ramasse-miettes
• Question sur la raison pour laquelle l’article de blog ne mentionne pas Go, avec la supposition que Go pourrait ne pas tirer profit de ces changements
• Comparaison avec une recréation des applets Java, avec la suggestion que réactiver les applets Java permettrait de résoudre de nombreux problèmes