Firefly – A new compiler and runtime for BEAM languages

https://github.com/GetFirefly/firefly

by mmcclure • 3 years ago

245 50 3 years ago

github.com

rektide2• 3 years ago

Apologies, what is the sell here? Lots of usage instructions & details but why use this vs Beam actual?

zacksiri• 3 years ago

I 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.

throwawaymaths2• 3 years ago

If 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

bhaney• 3 years ago

Pretty 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• 3 years ago

Phoenix+LiveView already seems to do this really well—what's the niche for an Elixir SPA?

manveru• 3 years ago

See the about section: 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.

rektide2• 3 years ago

Great! 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.

rurban2• 3 years ago

Also the BEAM bytecode compiler and runtime are incredibly slow and unoptimized. It doesn't matter much for process handling and IO dominant workloads, but you would not want to run it with normal tasks.

An AOT compiler with better optimizations will run circles around BEAM on benchmarks.

rahimnathwani• 3 years ago

Previous discussion (7 months ago, 45 comments):

https://news.ycombinator.com/item?id=32703414

bcardarella2• 3 years ago

This 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

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• 3 years ago

This 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• 3 years 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-...

bcardarella2• 3 years ago

yeah I know, I head-desked when I saw that. Can't win them all

martin_a• 3 years ago

Adobe also released a project called "Firefly". Not sure if this will be searchable after that.

https://www.adobe.com/sensei/generative-ai/firefly.html

rkangel3• 3 years ago

Forget 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).

lpil2• 3 years ago

Check out the existing AtomVM if you've not for that use case.

https://github.com/atomvm/AtomVM

bmitc2• 3 years ago

You may be already aware of it, but just in case, there is the Nerves project: https://nerves-project.org/

iudqnolq• 3 years ago

embedded Linux != microcontroller

katspaugh• 3 years ago

For 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.

chrsig• 3 years ago

i'm aware of erlang and elixer -- what other languages run on BEAM?

almery• 3 years ago

A couple others are:

https://lfe.io/ https://gleam.run/

greybox• 3 years ago

While 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• 3 years ago

I 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

Firefly – A new compiler and runtime for BEAM languages

Related Stories