Comment by nu11ptr
6 days ago
It is still a bit early, but I'm majorly bullish on WASM for multiple use cases:
1. Client side browser polyglot "applets" (Java applets were ahead of their time IMO)
2. Server side polyglot "servlets" (Node.js, embedded runtimes, etc.)
3. Language interop/FFI (Lang A -> WASM -> Lang B, like wasm2c)
Why is #3 so interesting? The hardest thing in language conversion is the library calls. WASI standardizes that, so all the proprietary libs will eventually compile down to WASI as a sort of POSIX/libc like layer. In addition, WASM standardizes calling convention. The resulting new source code may not look like much, but it will solve the FFI calling convention/marshalling/library issues nicely.
I’m not sure how it solves the FFI problem. Lowest common denominator calling conventions don’t make it any easier to bridge languages than it already is.
C calling conventions are already the standard for FFI in native code, and that means dropping down to what can be expressed in C if you want to cross that boundary.
As far as Go is concerned, the Wasm sandbox makes the (addressable, C) stack explicit, which solves at least some of the issues CGO has to deal with.
It's not a panacea, though; it introduces other issues.