Elixir + WASM -> will it happen?

Tags: #<Tag:0x00007f8ea07cf548>

  • If this has been asked here before, please point me to where it was asked as I didn’t find it when I searched the forum. Maybe a mailing list somewhere, but I didn’t find it.

I think I’m not alone when thinking about the awesome possibility of using Elixir for both backend and frontend work. I honestly think that this would be a massive win for Elixir. It would be awesome!! With that said, here are a couple of questions:

  1. What are some of the tradeoffs that we’d make when using Elixir for both (front + back)end development? I don’t know much about WASM to have an opinion/idea of what to expect here. But, I know a lot of folks here do.

  2. Is there anything holding the Elixir + WASM effort back? Is it just open source + time to get it working? Is there some technical challenge that makes this a pain? If there are, could you please list them?

  3. Is WASM on the roadmap for Elixir at all?

There seems to be a library that started trying to accomplish this:

Thanks! Excited to hear more about this!


There is already elixir script, which compiles elixir to JavaScript, I’m not sure if there are plans to move it to generate WASM though.


There’s also a thread here you might find interesting:

And here’s the ElixirScript thread:

I would love to be able to use Elixir instead of JS on the front end as well :003:


Ah, fantastic! I guess I didn’t search WebAssembly, just WASM… oh well, thanks for pointing this out @AstonJ!


WASM is getting proper threads in the spec soon, so with that it makes it even easier and better to compile the VM itself via to webassembly as well.


Wouldn’t the dynamic typing and uniqueness of the BEAM make compiling to WebAssembly more difficult than something like Rust or OCaml? I would expect static typing to make that conversion a lot easier. How much OTP could operate as normal given Elixir -> WASM compilation?

Maybe a WebGL on WASM remote controlled Drab sort of deal would be feasible? Flutter’s approach to cutting out the cruft and using OpenGL directly seems pretty compelling - I wonder if something similar could be done with WASM and WebGL? We’ll get 60+ fps web apps without Javascript one way or another - that I’m sure of.


The BEAM has some assembly in it so that would need to be rewritten, but otherwise the rest of the functionality can be shimmed not too hard, just take time. :slight_smile:
But I could see it as fully operational.


This might be related (@bryanjos is the maintainer):


I think I’m interested to see if there are any projects out there trying to compile BEAM VM to WebAssembly. Could a release be a good target to compile to WebAssembly? Could the LLVM backend for Erlang be a good place to start looking?

As far as Elixir itself to WebAssembly, I don’t know if the lack of a garbage collector in WebAssembly will be a show stopper. That would be something that would need to be answered

Threading shouldn’t matter as much. Processes are about concurrency, not parallelism.

There are a lot more questions than answers at this point. Long term goals that are good to shoot for.

In the mean time, there is ElixirScript, lol. But seriously if there is more attention and contributions to it, it could work and maybe slowly, move to WebAssembly when it’s more ready


The BEAM already has it’s own GC, using javascript’s GC in the BEAM ecosystem would be radically inefficient as they are substantially different operating models.


Yeah if the BEAM was compiled to it, that would not be an issue. I meant if going directly from Elixir to WebAssembly