Web assembly

[Brian Cardarella]

This is more of a "what if?" post than anything.

I am curious if there has been any discussion on either the Elixir side or Erlang side around Web Assembly. Is it a viable compilation target? Could there be benefits to the Elixir community? What type of efforts would be necessary to make this a reality?

[Brian Cardarella]

Bringing this back up as it never got any traction.

I'm seeing more and more of Elixir's competing languages getting some attention for web assembly:

Rust: https://davidmcneil.github.io/the-rusty-web/

Go: https://github.com/golang/go/issues/18892

Thoughts on discussion around an Elixir effort?

[José Valim]

If someone wants to tackle this, there are some options to be taken:

1. Compile Erlang Abstract Code to asm.js

2. Compile Core Erlang to asm.js

3. Rely on the llvm backend for hipe, which compiles to native, to compile to webassembly instead

4. Experimental: Compile Elixir AST to asm.js. We have spent the last weeks improving the Elixir compiler to allow Elixir developers to work on the Elixir AST instead of the formats above. The advantage of doing so is that you can introduce constructs to the Elixir syntax that targets specific backends

If someone is interested in playing with any of those options and you would like to chat about it, please ping me on IRC or privately by e-mail.

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/a437e695-d491-4abc-8a73-505912bcb79f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lance Halvorsen]

My understanding was that previously, web assembly didn't support automated GC, so that only languages with manual memory management were viable options. Has that changed?

.L

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2B0iKCo016y%2BFBVgXYh47eNAiGzatHrtEbZVqgbbREe3A%40mail.gmail.com.

[Brian Cardarella]

Confirm, for wasm 1.0. 1.1 is targeting GC

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/a437e695-d491-4abc-8a73-505912bcb79f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

[Brian Cardarella]

From what I've been reading on wasm is that pretty much everyone is waiting on the GC feature. 1.0 is more of a foot in the door release.

[Lance Halvorsen]

Interesting. Thanks for that. I'm curious how much of BEAM process semantics will be able to carry over to the web assembly vm as well.

.L

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/f3fc0bd4-285f-47e3-9cef-38672471c043%40googlegroups.com.

[Xavier Noria]

Let me ask something from the greatest of the ignorances!

My understanding of the Erlang compilation is that you transform code down to BEAM bytecode, going through a number of steps. The VM is register-based but even at the opcode level has direct support for Erlang semantics like mailboxes. For example, I believe blocking in `receive` basically becomes

    http://erlangonxen.org/more/beam#i_loop_rec

and

    http://erlangonxen.org/more/beam#wait

and friends. Removing a message is

    http://erlangonxen.org/more/beam#remove_message

So, we have some primitive opcodes for working with registers and call functions, say, but then something that works at a higher level.

Wouldn't compiling to other targets imply that you need to write all that builtin stuff yourself?

[José Valim]

Wouldn't compiling to other targets imply that you need to write all that builtin stuff yourself?

Theoretically yes but there are "options" such as:

  1. Do not perform translation based on the OPS code but instead on a higher level language, such as Core Erlang, so you are not tied to certain OPS code

  2. If you don't want to (or can't) implement all of the VM concurrency, you can always support a subset of operations/bytecode. That's the approach currently taken by elixirscript. It does not support PIDs, receive, etc.

[OvermindDL1]

Yes, very much so!