Comments (7)
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.
from firefly.
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.
from firefly.
Seems like the project is dead? :(
from firefly.
I really appreciate your thorough response @bitwalker
from firefly.
@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?
from firefly.
@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.
from firefly.
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.
from firefly.
Related Issues (20)
- CMake >= 3.20 not supported HOT 1
- offset_of HOT 2
- Implementing ETS HOT 9
- Krustlet Provider HOT 2
- Build errors ^^^^^^^^ feature has been removed
- Project Status HOT 10
- Need help for applying lumen
- GraalVM HOT 2
- can't build lumen on linux using the latest nightly nor nightly-2022-07-12 HOT 3
- Write page explaining change from lumen to firefly. HOT 3
- Build errors ^^^^^^^^ use of unstable library feature 'core_c_str' HOT 2
- Docker images of working Firefly installation Please HOT 3
- `firefly compile` fails during linking due to undefined reference to `init:boot/1` HOT 3
- Compiler will get segmentation fault for some kinds of `when` clauses on function HOT 1
- Some arithmetic expressions will not compile with error: failed to legalize operation 'cir.cast' HOT 1
- Overflow on a small integer causes a runtime error: `ImmediateOutOfRangeError`
- Error running example module on M1 HOT 1
- When will a precompiled toolchain package be available? HOT 2
- Can't build from source on develop HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from firefly.