[manveru]

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.

[rektide]

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.

[madsbuch]

There are details on this also: 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.

[rurban]

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.

[lpil]

Thankfully it is not slow! Last I measured it and its immutable data structures would beat Scala's immutable data structures in benchmarks.

[rkangel]

> Also the BEAM bytecode compiler and runtime are incredibly slow and unoptimized

Can you provide any citations for the BEAM runtime being unoptimised? In my experience it has been very carefully optimised over many years, generally prioritising latency over throughput.

[carlmr]

I'm more of an observer, since I'm not actively using Elixir, or Erlang, right now. I read that BEAM now supports JIT compilation. Doesn't this solve the performance issues for the most part?

EDIT: Apparently not LLVM JIT but that's beside the point.