5 ms·
Firefly – A new compiler and runtime for BEAM languages
- lmkdgbj 4y ago[flagged]
- rektide 4y agoApologies, what is the sell here? Lots of usage instructions & details but why use this vs Beam actual?
- zacksiri 4y agoI may be wrong but, “designed for WebAssembly” might be the key selling point here. I imagine we would be able to write elixir on the frontend with this.
- throwawaymaths 4y agoIf I were to try to do a straight shot at getting elixir on the frontend I'd just send bytecode up to the frontend and interpret it, either in js or wasm. Erlang bytecode is fairly straightforward, and especially if you stay single threaded you can make a reasonable approximation of the compute model[0]. The hardest parts I imagine would be coming up with an abstraction that lets you manipulate the DOM and test it while staying in the elixir test environment, which is insanely good. I don't see how firefly makes that particular challenge any easier. I feel like the dockyard folks just got rust crazy and decided to do this -- for reasons[1], rust is honestly not the best language to do a BEAM implementation in, which is I think why they pivoted to a compiler [0] except for the fact that a lot of libraries unnecessarily spawn processes. [1] https://www.erlang.org/doc/man/erts_alloc.html https://www.erlang.org/doc/man/erts_alloc.html
- illiarian 4y ago> If I were to try to do a straight shot at getting elixir on the frontend I'd ... use LiveView :)
- throwawaymaths 4y agoLike this proposes eventually obviating the need for things like LiveView.JS, LiveView hooks, etc.
- yellowapple 4y ago> except for the fact that a lot of libraries unnecessarily spawn processes. Well yeah, that's kinda the whole point of Erlang in the first place :)
- bhaney 4y agoPretty much exactly that, yeah. From the README: > The primary motivator for Firefly's development was the ability to compile Elixir applications that could target WebAssembly, enabling use of Elixir as a language for frontend development
- lolinder 4y agoPhoenix+LiveView already seems to do this really well—what's the niche for an Elixir SPA?
- rkangel 4y agoI'm a big fan of LiveView, but when you get to a very high degree of interactivity or anything that needs to work well offline or with bad signal quality then LiveView is not the right choice.
- POiNTx 4y agoFor very high degree of interactivity I've been working on LiveSvelte which might solve that issue for you. Your other points still stand though. https://github.com/woutdp/live_svelte https://github.com/woutdp/live_svelte
- victorbjorklund 4y agoYou can build an app that runs entirely in the browser eliminating the need to have a server and reducing latency. Of course it doesn't make sense for all use cases but for some apps it might make a lot of sense. For example that is how Liveview Desktop works.
- manveru 4y agoSee the about section: https://github.com/GetFirefly/firefly#about-firefly https://github.com/GetFirefly/firefly#about-firefly > The primary motivator for Firefly's development was the ability to compile Elixir applications that could target WebAssembly, enabling use of Elixir as a language for frontend development. It is also possible to use Firefly to target other platforms as well, by producing self-contained executables on platforms such as x86.
- rektide 4y agoGreat! Nice. Very neat possibilities here. I'd be very very interested to hear follow up, on how Firefly does actors. I feel like there's so many potential ways to target wasm, but the high concurrency spirit of Beam has such unique flavor. I'd love to read in & hear that spirit is well preserved.
- madsbuch 4y agoThere are details on this also: https://github.com/GetFirefly/firefly#runtime https://github.com/GetFirefly/firefly#runtime Generally it should be assumed that actors and their concurrency model is fully supported as that is a part of the core semantics for BEAM languages.
- illiarian 4y ago> as that is a part of the core semantics for BEAM languages. It's a part of the semantics of the runtime: - an actor is all but guaranteed to not bring down the runtime - an actor is all but guaranteed to never affect other actors - runtime knows how put processes to sleep until the message they listen to arrives. This means all functions are re-entrant. Well, any process is put to sleep after a cretain number of reductions so that no process takes away time from other processes. - runtime all but guarantees that process errors are a) isolated and b) propagated. That is when a process dies all other processes that monitor it are guaranteed to receive a notification. That's why supervision hierarchies in Erlang are possible
- 4y ago
- rahimnathwani 4y agoPrevious discussion (7 months ago, 45 comments): https://news.ycombinator.com/item?id=32703414 https://news.ycombinator.com/item?id=32703414
- bcardarella 4y agoThis is a project formerly known as Lumen, which myself and the other core devs presented on at ElixirConf a few years ago: https://www.youtube.com/watch?v=uMgTIlgYB-U https://www.youtube.com/watch?v=uMgTIlgYB-U A lot has changed since then. The name change came about because we found too many projects named "Lumen" also were launched around the same time or shortly thereafter. Originally I envisioned a path towards creating a new WASM framework to build web applications using Elixir. Since then LiveView has come out and has made this less of a concern for us. While WASM compilation will be possible and we hope to backfill the runtime needs for web development the real focus and interest in this project for me is... WASI compilation. With Firefly we will be able build self-contained binaries that will have all (many) of the benefits building applications with the BEAM and distributed systems. If WASI can run on something you should be able to compile your Elixir applications with Firefly and target your desired chipset. We recently reached a milestone that we are hoping to release a blog post about it in the near future.
- xcdzvyn 4y agoThis is pretty awesome. There's bound to be some fun stories about BEAM's internals, given its age. Have you considered Cranelift as an alternative backend like rustc is doing?
- ModernMech 4y ago> The name change came about because we found too many projects named "Lumen" also were launched around the same time or shortly thereafter. I’ve got bad news… https://news.adobe.com/news/news-details/2023/Adobe-Unveils-Firefly-a-Family-of-new-Creative-Generative-AI/default.aspx https://news.adobe.com/news/news-details/2023/Adobe-Unveils-...
- bcardarella 4y agoyeah I know, I head-desked when I saw that. Can't win them all
- martin_a 4y agoAdobe also released a project called "Firefly". Not sure if this will be searchable after that. https://www.adobe.com/sensei/generative-ai/firefly.html https://www.adobe.com/sensei/generative-ai/firefly.html
- rkangel 4y agoForget WASI, I'm interested in this project as a way to efficiently run Elixir on microcontrollers. It's a great model for embedded programming (not surprising given that was what it was designed).
- katspaugh 4y agoFor those who don't know (I didn't) – BEAM is the Erlang virtual machine. It supports many programming languages. This new compiler/runtime targets WebAssembly.
- greybox 4y agoWhile I appreciate this is cool project, and I enjoy writing Erlang & Elixir. What benefit is there to being able to run BEAM/OTP in the browser?
- jake_morrison 4y agoI have been thinking about using the Erlang concurrency and messaging model for brower-based applications. UI components operate in separate threads and communicate with the back end by sending and receiving async messages. Back-end components communicate with servers using async messages, then publish results to front-end components. This is similar to what Joe Armstrong was working on for X-Windows GUIs: https://erlang.org/workshop/2004/ex11.pdf https://erlang.org/workshop/2004/ex11.pdf