5 ms·

Anyone know how difficult Rust -> WebAssembly will be, compared to C++ -> WebAssembly? I'm hoping to switch some of my Go code to Rust, as i imagine Go -> WebAs

Anyone know how difficult Rust -> WebAssembly will be, compared to C++ -> WebAssembly? I'm hoping to switch some of my Go code to Rust, as i imagine Go -> WebAssembly will be much further out _(GC and all)_, so i'm hoping Rust is much sooner in the pipeline.

jfbastien 11y ago
"ridiculously easy": https://github.com/rust-lang/rfcs/issues/604 https://github.com/rust-lang/rfcs/issues/604
grayrest 11y ago
Should just be replacing Emscripten in the toolchain with Binaryen [1]. [1] https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen
- brson 11y ago
  This is actually unlikely to be Rust's solution (at least in the long term), because it requires running LLVM IR through emscripten to generate asm.js to generate wasm. Making Rust and emscripten use the same LLVM IR is difficult because emscripten has a large out-of-tree LLVM patch that Rust would need to share. The wasm backend though is in upstream LLVM, so rustc can use it directly, bypassing emscripten for translation of Rust.
brson 11y ago
Ridiculously easy. It's all but done already via the emscripten port [1]. The emscripten port though is hampered by needing a large out-of-tree patch to LLVM. Once the LLVM wasm backend is ready upstream there will be little left but to just turn it on. [1]: https://internals.rust-lang.org/t/need-help-with-emscripten-port/3154 https://internals.rust-lang.org/t/need-help-with-emscripten-...
tracker1 11y ago
It's worth noting that there are llvm compiler options for go. So as soon as llvm supports a wasm target, you should be able to keep your go code in tact, or at least minimal changes...
- kibwen 11y ago
  The initial release of WebAssembly won't have any support for well-integrated runtimes, which complicates support for any language that isn't C or C++ or Rust. Theoretically you could probably ship the Go runtime with each webpage, but I don't know how you'd interact with the DOM from there.
  - fizzbatter 11y ago
    Well DOM _(from my limited queries)_ is a bit further out anyway. On their design page, DOM and GC are actually lumped together[1]. That being said, i really want DOM access from Rust, so perhaps it's a moot point heh [1]: https://github.com/WebAssembly/design/blob/master/GC.md#gc--dom--web-api-integration https://github.com/WebAssembly/design/blob/master/GC.md#gc--...
    - kibwen 11y ago
      Interacting with the DOM from C++ or Rust via an opaque handle seems relatively straightforward compared to designing one-size-fits-all GC primitives that will enable multiple GCs to seamlessly interact (because remember, you may very well want code written in Go and Python and Javascript all on the same page, and they'll all want to manage the same DOM).

jfbastien 11y ago

"ridiculously easy": https://github.com/rust-lang/rfcs/issues/604 https://github.com/rust-lang/rfcs/issues/604

grayrest 11y ago

Should just be replacing Emscripten in the toolchain with Binaryen [1]. [1] https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen

brson 11y ago
This is actually unlikely to be Rust's solution (at least in the long term), because it requires running LLVM IR through emscripten to generate asm.js to generate wasm. Making Rust and emscripten use the same LLVM IR is difficult because emscripten has a large out-of-tree LLVM patch that Rust would need to share. The wasm backend though is in upstream LLVM, so rustc can use it directly, bypassing emscripten for translation of Rust.

brson 11y ago

Ridiculously easy. It's all but done already via the emscripten port [1]. The emscripten port though is hampered by needing a large out-of-tree patch to LLVM. Once the LLVM wasm backend is ready upstream there will be little left but to just turn it on. [1]: https://internals.rust-lang.org/t/need-help-with-emscripten-port/3154 https://internals.rust-lang.org/t/need-help-with-emscripten-...

tracker1 11y ago

It's worth noting that there are llvm compiler options for go. So as soon as llvm supports a wasm target, you should be able to keep your go code in tact, or at least minimal changes...

kibwen 11y ago
The initial release of WebAssembly won't have any support for well-integrated runtimes, which complicates support for any language that isn't C or C++ or Rust. Theoretically you could probably ship the Go runtime with each webpage, but I don't know how you'd interact with the DOM from there.
- fizzbatter 11y ago
  Well DOM _(from my limited queries)_ is a bit further out anyway. On their design page, DOM and GC are actually lumped together[1]. That being said, i really want DOM access from Rust, so perhaps it's a moot point heh [1]: https://github.com/WebAssembly/design/blob/master/GC.md#gc--dom--web-api-integration https://github.com/WebAssembly/design/blob/master/GC.md#gc--...
  - kibwen 11y ago
    Interacting with the DOM from C++ or Rust via an opaque handle seems relatively straightforward compared to designing one-size-fits-all GC primitives that will enable multiple GCs to seamlessly interact (because remember, you may very well want code written in Go and Python and Javascript all on the same page, and they'll all want to manage the same DOM).