3 ms·

WASM is a specification. So when you compile to it, you compile to the specification. Any language runtime (be it JavaScript via V8, Go, or whatever) or languag

WASM is a specification. So when you compile to it, you compile to the specification. Any language runtime (be it JavaScript via V8, Go, or whatever) or language interop via compilation (Rust, C, C++) can interact with a WASM binary if their toolchain supports understanding it. Thats the key here. I can take my JS, compile it to WASM, and Rust can use it as a module because its compiler understands WASM (in simple terms). This all requires a WASM runtime of course, no doubting that. However, the mere fact I can take two languages, compile one to WASM and use that as the module in that other language, is what I'm talking about. And WASM compat is taking off pretty well so far. I admire Truffle's approach, it might prove to be long term better in solving this problem, because languages can move at the speed they want to move, and the interop story doesn't really change. Where as with WASM, you have to keep up with the WASM specification and runtimes, which could be a headache if not done in a community oriented, deliberate way. All that is to say, its up the language toolchain to deal with compiling that language to WASM, but once its WASM, its portable

mike_hearn 3y ago
I'd be curious to see a demonstration codebase where JS or other dynamic languages are compiled to WASM and then loaded into something else with automatic FFI at the module level. Because I think you'd still need to work with v8::Value objects or an equivalent to use JS from C++, WASM or not. WASM isn't meant to be a compilation target for languages like JS, what dynamic languages need from a compiler is very different to what Rust needs.
- no_wizard 3y ago
  To be clear, I'm talking about the following: I can write some code or use modules written in JavaScript that compile to WASM. I can use that compiled output with any runtime that can import WASM and expose its interface natively. To that end, I could use it in Rust, no problem. The same is in reverse. I can write a Rust program, compile to WASM, and use it in JS runtime (lots of projects do this already, actually. esbuild does this with Go as well). Right Now there are of course limitations, however if current trajectory holds, you'll be able to just import wasm directly into a compat runtime. So I can take the JS to WASM output and share it to any language to can understand it. This is, as I understand it, the advantage of WASM in the future tense (and if you use JavaScript, its kind of present tense, esp. with import assertions)

mike_hearn 3y ago

I'd be curious to see a demonstration codebase where JS or other dynamic languages are compiled to WASM and then loaded into something else with automatic FFI at the module level. Because I think you'd still need to work with v8::Value objects or an equivalent to use JS from C++, WASM or not. WASM isn't meant to be a compilation target for languages like JS, what dynamic languages need from a compiler is very different to what Rust needs.

no_wizard 3y ago
To be clear, I'm talking about the following: I can write some code or use modules written in JavaScript that compile to WASM. I can use that compiled output with any runtime that can import WASM and expose its interface natively. To that end, I could use it in Rust, no problem. The same is in reverse. I can write a Rust program, compile to WASM, and use it in JS runtime (lots of projects do this already, actually. esbuild does this with Go as well). Right Now there are of course limitations, however if current trajectory holds, you'll be able to just import wasm directly into a compat runtime. So I can take the JS to WASM output and share it to any language to can understand it. This is, as I understand it, the advantage of WASM in the future tense (and if you use JavaScript, its kind of present tense, esp. with import assertions)