4 ms·
GC semantics are highly specific and coupled to the language. Of course WASM couldn’t (and shouldn’t!) deal with that. I mostly agree with your overall point t
by orf 4y ago
GC semantics are highly specific and coupled to the language. Of course WASM couldn’t (and shouldn’t!) deal with that.
I mostly agree with your overall point though. I’m not making the point that WASM right now (or even later) is the future of deploying backend services, however it is somewhat of a universal VM. If it’s a useful one is yet to be seen.
- cmrdporcupine 4y agoYes, of course they're highly specific. And that's my point. Why would I run a GC language inside my WASM runtime, at a 2-3x or more performance overhead? Instead of just running that languages' existing runtime which has been tuned for years, and already provides its own virtual machine? What is the actual benefit? Putting it more clearly: Most services development is done in languages that have their own virtual machine (JS/TS, Go, JVM, Python, .NET). In what world does it make sense to run that VM inside another VM? Finally, I think the experiences over the last 20 years around .NET and the JVM should have shown there is in fact not really such a thing as a truly universal abstract VM. A well-written VM tends to be written towards supporting the language(s) it is built for. ... Not unless you're willing to throw away almost all added value, and then you start looking like WASM. And then what's your value beyond native code, running on the hypervisor and/or in a container? (There are in fact proposals for adding GC hooks in WASM. I'd have to spend some time reading up on them to evaluate whether they address my objections.)