6 ms·

See the about section: https://github.com/GetFirefly/firefly#about-firefly https://github.com/GetFirefly/firefly#about-firefly > The primary motivator for Fire

See 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 3y 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.
- madsbuch 3y ago
  There 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 3y 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
    - macintux 3y ago
      I would argue it’s intrinsic to the language itself. In fact I did as a pedagogical tactic. https://youtu.be/E18shi1qIHU https://youtu.be/E18shi1qIHU
      - illiarian 3y ago
        You can't have those things without runtime support. E.g. in Go/Rust a panic will kill the app. In Erlang an equivalent catastorphic failure in a process will kill the process, will notify the monitoring processes, the app will keep on running.
    - madsbuch 3y ago
      > It's a part of the semantics of the runtime: This is implied. It would be absurd to have a different static and runtime semantics. in fact, the core goal for formal methods is a statically be able to reason about runtime dynamics. Just like it would be absurd to build a compiler for C where "+" in fact is treated as "-", it would be absurd to build a compiler and runtime system for, eg., Elixir that is not able to execute GenServers.
      - illiarian 3y ago
        > This is implied. You'd be surprised how many people miss that runtime drives this. I've seen many discussions where people claimed "you can implement all this is a library" :) > it would be absurd to build a compiler and runtime system for, eg., Elixir that is not able to execute GenServers. Well, Akka did it on top of JVM: https://doc.akka.io/docs/akka/current/typed/fault-tolerance.html#supervision https://doc.akka.io/docs/akka/current/typed/fault-tolerance.... Can't say about its limitations though.
        madsbuch 3y ago
        > You'd be surprised how many people miss that runtime drives this. I've seen many discussions where people claimed "you can implement all this is a library" :) I undrstand, everything concurrency is definitely not easy to implement in "User land" and is something you want good primitives for – why I am also amaxed over this project as they must have embedded that functionality (the scheduler) in the executable (Which they also say they did). > Well, Akka did it on top of JVM ... > Akka is a toolkit for building highly concurrent, distributed, and resilient message-driven applications for Java and Scala. Akka does not seem to claim that they build a new runtime for BEAM languages?
rurban 3y 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.
- carlmr 3y ago
  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.
  - debugnik 3y ago
    LLVM? Pretty sure they scrapped that for being slow, BeamAsm is a JIT written from scratch. Edit: It actually uses part of AsmJit, not quite from scratch, my mistake.
    - carlmr 3y ago
      Updated my comment
  - ramchip 3y ago
    It does JIT with AsmJit (not LLVM).
    - carlmr 3y ago
      Updated my comment
  - toast0 3y ago
    BEAM does have a JIT on some platforms (iirc, amd64 and aarch64), but it's not an optimizing JIT like you might be familiar with from Java's Hotspot and similar systems. In BEAM Asm, the design is for the whole VM to either be interpretted (status quo) or native (JIT). In JIT mode, all the loaded modules are translated to native code as they're loaded; this needs to be fast or startup times are delayed, IIRC, there is an optimization path, but it's simple. There's no reoptimization of hot code paths later either; just the one time process. The main benefit of this process is to remove a specific part of interpretation overhead, the instruction unpacking and dispatch overhead is eliminated. This can be significant for some applications and not for others, but it's really the main target, any other optimizations that happen are a bonus.

rektide 3y 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.

madsbuch 3y ago
There 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 3y 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
  - macintux 3y ago
    I would argue it’s intrinsic to the language itself. In fact I did as a pedagogical tactic. https://youtu.be/E18shi1qIHU https://youtu.be/E18shi1qIHU
    - illiarian 3y ago
      You can't have those things without runtime support. E.g. in Go/Rust a panic will kill the app. In Erlang an equivalent catastorphic failure in a process will kill the process, will notify the monitoring processes, the app will keep on running.
  - madsbuch 3y ago
    > It's a part of the semantics of the runtime: This is implied. It would be absurd to have a different static and runtime semantics. in fact, the core goal for formal methods is a statically be able to reason about runtime dynamics. Just like it would be absurd to build a compiler for C where "+" in fact is treated as "-", it would be absurd to build a compiler and runtime system for, eg., Elixir that is not able to execute GenServers.
    - illiarian 3y ago
      > This is implied. You'd be surprised how many people miss that runtime drives this. I've seen many discussions where people claimed "you can implement all this is a library" :) > it would be absurd to build a compiler and runtime system for, eg., Elixir that is not able to execute GenServers. Well, Akka did it on top of JVM: https://doc.akka.io/docs/akka/current/typed/fault-tolerance.html#supervision https://doc.akka.io/docs/akka/current/typed/fault-tolerance.... Can't say about its limitations though.
      - madsbuch 3y ago
        > You'd be surprised how many people miss that runtime drives this. I've seen many discussions where people claimed "you can implement all this is a library" :) I undrstand, everything concurrency is definitely not easy to implement in "User land" and is something you want good primitives for – why I am also amaxed over this project as they must have embedded that functionality (the scheduler) in the executable (Which they also say they did). > Well, Akka did it on top of JVM ... > Akka is a toolkit for building highly concurrent, distributed, and resilient message-driven applications for Java and Scala. Akka does not seem to claim that they build a new runtime for BEAM languages?

rurban 3y 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.

carlmr 3y ago
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.
- debugnik 3y ago
  LLVM? Pretty sure they scrapped that for being slow, BeamAsm is a JIT written from scratch. Edit: It actually uses part of AsmJit, not quite from scratch, my mistake.
  - carlmr 3y ago
    Updated my comment
- ramchip 3y ago
  It does JIT with AsmJit (not LLVM).
  - carlmr 3y ago
    Updated my comment
- toast0 3y ago
  BEAM does have a JIT on some platforms (iirc, amd64 and aarch64), but it's not an optimizing JIT like you might be familiar with from Java's Hotspot and similar systems. In BEAM Asm, the design is for the whole VM to either be interpretted (status quo) or native (JIT). In JIT mode, all the loaded modules are translated to native code as they're loaded; this needs to be fast or startup times are delayed, IIRC, there is an optimization path, but it's simple. There's no reoptimization of hot code paths later either; just the one time process. The main benefit of this process is to remove a specific part of interpretation overhead, the instruction unpacking and dispatch overhead is eliminated. This can be significant for some applications and not for others, but it's really the main target, any other optimizations that happen are a bonus.