Bringing garbage collected programming languages efficiently to WebAssembly (v8.dev)

Article summary

The article discusses two approaches to bringing garbage collected programming languages to WebAssembly: the traditional porting approach and the WasmGC porting approach. The traditional approach involves recompiling an existing language implementation to WebAssembly, while the WasmGC approach involves compiling the language to WebAssembly's garbage collection constructs. The WasmGC approach has several advantages, including smaller binary size and better integration with the WebAssembly VM. However, it also requires new work in toolchains and VMs.

Main themes

• WebAssembly garbage collection
• language porting approaches
• JVM and multilanguage support
• threads and concurrency
• performance and abstraction
• platform maturity and adoption
• language design and tradeoffs

What commenters say

• Some commenters believe that WebAssembly's garbage collection support is a significant step forward, but others think it's not a new concept and has been done before in other platforms.
• The JVM is seen as a mature platform for running multiple languages, but its success in this area is attributed to the large number of existing Java binaries rather than the JVM itself being particularly good at supporting alternative languages.
• There are differing opinions on the usefulness of threads in WebAssembly, with some seeing them as a necessary evil and others as a flawed model of concurrency.
• The introduction of WebAssembly threads would require significant work on garbage collection, and some commenters are skeptical about the performance overhead of abstraction inversion.
• Some languages, such as Kotlin, are gaining popularity on the JVM, but others argue that this is due to Google's influence on Android rather than any inherent advantage of the JVM.
• The idea that WebAssembly could become a primary target for multiple languages is seen as promising, but also fraught with challenges and uncertainties.
• The relationship between WebAssembly and the JVM is seen as complex, with some commenters noting that WebAssembly could potentially learn from the JVM's experiences with garbage collection and multilanguage support.