Strikes me though that all these "managed-memory language VM inside a a WASM VM" projects for WASM keep having to build out garbage collection support (or run an existing GC inside WASM) for their runtimes. It's a bit of a stacking turtles problem, and seems wildly inefficient. I keep wondering how far off GC support for WASM runtimes is.
In the meantime, while this is neat, I feel like it's a mis-use of what WASM is most suited for: cross-compiling C/C++ etc binaries to a "web" target. WASM as a container for multiple language runtimes seems wildly inefficient.
In the case of CheerpJ the virtual machine itself is pure C++ compiled to WASM, but the JIT-ted code and the objects are pure JS. Garbage collection is natively handled by the browser.
As WASM GC stabilizes we will consider supporting it as well.
Ah, this is an interesting approach. Does JITing over to JS introduce problems with concurrency support though, given the lack of threads in the JS runtime?
WASM Garbage collection is coming pretty soon. Currently, it's behind a feature flag in Chrome. I think the chrome flag for GC is due to be removed in a few months. I don't know when Firefox and Safari will roll out support. But I assume they won't be that far behind.
One of the things I'm following that will use garbage collection support is the Kotlin wasm compiler which is currently available as an experimental option with kotlin 1.8 and beyond. And of course with wasmer and wasmtime, it will also be possible to target edge computing with this eventually (as they roll out gc support in the next months). Fair warning, this stuff is very cutting edge currently. Wait six months or so for this to become more usable. The upcoming kotlin 2.0 is probably going to be seeing some usable early access version.
There is already some experimental wasm support for Jetpack Compose multiplatform in the works as well. Currently you'd mostly use the kotlin-js compiler for that on the web but pretty soon you should be able to compile to wasm instead. This will work both with components that render to a canvas as html based web components. Advantages of kotlin wasm over kotlin-js: faster compilation and loading speeds. And having used kotlin-js, faster compilation speeds are very much welcome.
If you are into multiplatform UI development, another thing that is interesting with this is the IOS support in compose. So with compose you should be able to target Android, IOS (native), Web (js and wasm) and desktop (jvm). Interesting new framework with not a lot of alternatives beyond react native and Flutter so far. And of course Kotlin is popular on Android and for cross IOS/Android development already. This stuff will take some time to mature but there was a lot of buzz around this topic at kotlin conf a few weeks ago. And of course with wasm and wasm components, you'd be able to do cross platform UI development and integrate the same components via wasm on each platform rather than having to engineer bespoke components for each platform.
Strikes me though that all these "managed-memory language VM inside a a WASM VM" projects for WASM keep having to build out garbage collection support (or run an existing GC inside WASM) for their runtimes. It's a bit of a stacking turtles problem, and seems wildly inefficient. I keep wondering how far off GC support for WASM runtimes is.
In the meantime, while this is neat, I feel like it's a mis-use of what WASM is most suited for: cross-compiling C/C++ etc binaries to a "web" target. WASM as a container for multiple language runtimes seems wildly inefficient.