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:
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.
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?
Is WASM on the roadmap for Elixir at all?
There seems to be a library that started trying to accomplish this:
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.
But I could see it as fully operational.
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.
Are there any active efforts underway to port BEAM to WASM? If not, what is the most appropriate forum to advocate for this to happen?
As a web developer wanting to “get into” Elixir (or even Erlang), this would be one way to use Elixir as part of my everyday development efforts without requiring conversion of the server-side runtime (although it would also help to advocate for that change too).
I wish Elixir could become a mainstream choice for client-side application programming.
Yes. DockYard is hiring someone to tackle this effort by first seeing if it’s possible and then implement it. Brian Cardarella (CEO of DockYard) said that you shouldn’t wait for it since it will be a multi-year effort.
I made a brief attempt at it but I got inundated with compile errors that look difficult to tackle without solid C experience. For anyone who wants to try, here’s the basics of how I got started. You’ll need emsdk installed and activated first:
# Clone Erlang repo
git clone https://github.com/erlang/otp.git
cd otp
git checkout OTP-21.0.9
# Some of the build stuff references the environment variable $ERL_TOP
export ERL_TOP=`pwd`
# Start with some autoconf stuff for the Erlang RunTime System (erts). Though it may not
# actually make a difference here, I'm prefixing these commands with `emconfigure` command
# to make sure that emscripten's headers are used instead of the default system headers
cd erts
emconfigure autoheader
emconfigure autoconf
# Back in the root, configure and compile. The flag --enable-bootstrap-only causes only the
# core runtime system to be compiled
cd ..
emconfigure autoconf
emconfigure ./configure --enable-bootstrap-only
emmake make
At this point, be prepared for a mountain of compiler errors. The exact errors differ when running it on Mac vs Ubuntu. Many of them occur in parts of the code that can be disabled with preprocessor defines, so it’s possible that the right set of defines could get it to work.
There’s a section of the Erlang docs that describes cross-compilation, but I didn’t find anything I knew how to make use of. To anyone at Dockyard or elsewhere giving this a whirl, good luck, and please let us know how it’s going!
From the other perspective (i.e. running Wasm in Elixir), we’ve been working on a virtual machine called WaspVM for the past few weeks at Elixium Network, if anyone is interested in that.
