I could be missing something important about WASM (or BEAM), but why are you compiling to WASM rather than JS? Seems to me that's losing on most fronts: performance, effort and code size. WASM is a reasonable compilation target for C; not so much for untyped languages with a GC, while JS is a decent compilation target exactly for such languages. What's the gain with WASM?
I think you're looking at this as a transpiler, it is not. We are implementing a runtime which most definitely wouldn't be performant or of a reasonable footprint size in JS.
Beating V8's GC and JIT would be extremely hard given they're of pretty good quality, and I don't even know if you could write a JIT in WASM (can you?). Do you think implementing an interpreter and a GC in WASM could be faster/smaller than exploiting one of the best JITs out there and easier/smaller than taking advantage of a built-in GC? Moreover, you seem to be giving up on dynamic code loading in exchange for worse performance.
I'm not trying to challenge you, I just work on VMs and I don't understand the thought process behind such an unusual decision, but that could be because I don't know much about WASM. What am I missing?
This question is better fielded by Paul, Luke, or Hans. I gave them the week off after the conference so I cannot promise they'll reply here on HN. If you want to contact me over email (brian at dockyard.com) I can try to have them follow up on this.
This isn't a complete answer to you're question, but one note. They aren't building an interpreter in wasm. They are compiling elixir to native wasm. Elixir code wouldn't be shipped to the client.
