Elixir example?

[superchris]

Hello, not sure if this project is still active, but thought I'd check to see how feasible it would be to get an example of running Elixir code in firefly. Even just a hello world kind of a thing. I'm give a talk on the state of WebAssembly and Elixir so I thought I'd see where things are at.

[yasoob]

Seems like the project is dead? :(

[bitwalker]

It's on indefinite hiatus at the moment, largely because I haven't had any time to allocate to it. Working on it isn't my day job currently, and my actual day job is keeping me crazy busy, so I have basically no time left over for anything.

As far as the state of Elixir and Wasm goes, I think we're definitely getting closer to having the primitives in Wasm needed to really make it practical, but we're not there yet. The main things we still don't have are proper threading support and stack switching primitives. Once those land in some form, it will change the game.

The biggest challenge with this project has been working around the limitations WebAssembly has imposed on languages that make liberal use of things like tail-call optimization, green threading, non-local control flow, etc. There are various solutions/workarounds to each, but either they fall apart due to some specific constraint (or due to significant overhead); or they fall apart when it comes time to integrate all of the pieces together. The lack of a unifying control flow primitive is easily, by far, the biggest hurdle. On a typical architecture, e.g. x86_64, you are given the raw materials and can build whatever primitives you want. That is not the case for WebAssembly, where those "raw materials" are not given to you, and so it is virtually impossible to build suitable primitives.

Whenever the stack-switching working group (within the Wasm CG) lands something like delimited continuations or stackful coroutines, or even something lower level than that which we can use, then I'll be all over this project again. Until then, I'm biding my time and keeping tabs on things. If I manage to free up time again, or something lands that changes the game like I mentioned, then I'll be back at it again. It sucks to not be able to hammer away at this still, because I invested a very non-trivial amount of my time and energy into it (not to mention DockYard invested a non-trivial amount of company resources into it) - but it is what it is for now.

[yasoob]

I really appreciate your thorough response @bitwalker

[sleipnir]

@bitwalker I have a question just out of curiosity. Would it be possible to continue the project taking into account only the x86_64 architecture while WASM does not solidify?

[bitwalker]

@sleipnir It's certainly possible yes. It's also not like there is nothing to do at the moment, there is plenty yet to be done to flesh things out and improve the compiler and runtime libraries. However, doing so just to target x86_64 (or AArch64, etc) might not be the most pragmatic use of ones time, compared to just shipping the BEAM. It would be working on Firefly for Firefly's sake, i.e. for fun, for learning, for yourself; to see what's possible. Regardless of anything else, that's always going to be the case for me.

That said, even if it isn't pragmatic, I do think there is value in continuing to work on the project without Wasm. There are a handful of areas in which AOT compiling Erlang/Elixir has a lot of very interesting problems: static analysis/optimization, type inference (especially with Elixir getting a gradual type system), as well as the complexities involved in integrating with a rich, powerful runtime like the BEAM. I've done a bunch of exploration across those topics already for Firefly, but it is a never-ending real rabbit hole, with tooling and research evolving constantly.

I do think it would be important to keep Wasm/embedded systems in mind while continuing to develop the project, so I don't think it would be a case of discarding that completely, but rather putting those efforts on hold until things fall into place.

[superchris]

Thanks for all that @bitwalker. The reason for the original question was that I'm giving a talk on WASM and Elixir at Codebeam next month. I'll probably be talking more about hosting from Elixir than guesting (building WASM modules) but I would love to give an update to folks there on Firefly. Other than what you've shared already, anything you'd like me to add? Any specific calls to action or suggestions for people that want to get involved?

Also, are you tracking the WASI releases? It sounds like they are hard at work implementing async things in the next release (P3). I'm not quite sure how their work overlaps with the other things you mentioned.

[sleipnir]

That said, even if it isn't pragmatic, I do think there is value in continuing to work on the project without Wasm. There are a handful of areas in which AOT compiling Erlang/Elixir has a lot of very interesting problems: static analysis/optimization, type inference (especially with Elixir getting a gradual type system), as well as the complexities involved in integrating with a rich, powerful runtime like the BEAM. I've done a bunch of exploration across those topics already for Firefly, but it is a never-ending real rabbit hole, with tooling and research evolving constantly.

@bitwalker Yes, that's how I think, I believe that for locations like Cloud or Edge a lighter execution time would be ideal, for example in Cloud environments hot reloading is certainly not as attractive, all this extra BEAM stack takes its toll on these locations and an alternative would be lovely. I believe that Wasm support is already a special extra, but I see a lot of value in this project here also in other usage scenarios like the ones I just mentioned.