Of course, if you have a bunch of languages that compile to JavaScript, they all share the same low-level object layout and garbage collector. This VM has a lot of momentum.
The problem is that languages that are genuinely different from JavaScript (such as Dart and Go via gopher) have their own static linkers that generate a big blob of JavaScript. To really do interop right, you need to share a common linker and data format for public API calls. And to make this efficient, it needs to handle inlining and tree-shaking. At that point you might as well use JavaScript or a light overlay language like TypeScript.
With wasm, similarly, a common language runtime should probably have its own linker that combines and optimizes libraries and emits a wasm file.
Re:Rust and WebAssembly in 2019
by SquareWheel on Sunday December 16, 2018 @04:10AM
(#18692363)
It would be neat if they could be cached as language-specific GCs, rather than having to be bundled individually with each application.
Re:Rust and WebAssembly in 2019
by danShumway on Sunday December 16, 2018 @10:01AM
(#18693308)
This is something that interests me as well. If you have separate WASM binaries, right now they have to be on separate threads. For many languages, that may not matter, but it would be interesting to see if there was some way to split up a WASM binary on the same thread and apply caching to some of it.
This is probably not a terrible thing, since a native garbage collector in WASM (unless it was designed in an extremely simplistic, low-level form) would also probably not be suitable for the diversity of the languages that want to include one.
It is (probably) better for individual languages to write their own, even if that increases binary sizes.