DockYard R&D: FireFly Optimizes Your Elixir Compilation
As someone who&#x27;s the exact target audience of this post (deploying Elixir apps in production), I have no idea what this PR piece is trying to say.<p>&gt; Unlike BEAM it compiles applications ahead of time, allowing Lumen to perform optimizations BEAM can’t.<p>What does this mean? Erlang&#x2F;Elixir <i>are</i> AOT-compiled languages. They&#x27;re compiled into bytecode. (Also, &quot;BEAM&quot; is not a compiler, but a bytecode VM which executes the bytecode emitted <i>by</i> the compiler.)<p>Do they mean that they further compile the BEAM bytecode to native host-ISA object code? Or did they write alternative Erlang and Elixir compilers, to compile these HLLs directly to host-ISA object code, skipping both the language runtime and BEAM bytecode entirely? Do they mean &quot;compiles applications&quot; literally, in the sense of Whole-Program Optimization?<p>In short — is this something like GraalVM&#x27;s Native Images; or something like an AOT version of BEAM&#x27;s HiPE extension; or something else?<p>&gt; FireFly is able to compile Elixir applications without having to run through the Erlang Virtual Machine.<p>So is the key benefit here that the <i>compilation</i> is faster because it&#x27;s not running on the BEAM (good for e.g. CI); or is the key benefit that the <i>resulting executable</i> is faster because it&#x27;s not running on the BEAM?<p>Also, there are some questions I have that this post didn&#x27;t even try to answer. E.g.:<p>It is my understanding that the the bytecode-ness of the Erlang VM is crucial to the lightweight bounded-runtime cooperative-scheduling mechanism that allows Erlang&#x2F;Elixir code to be high-concurrency + soft-realtime. (Effectively, every ISA op implicitly decrements a per-actor reduction-counter as part of its implementation; and the yield-point checks are <i>also</i> inside the impls for certain BEAM ISA ops, rather than being their own explicit BEAM ISA instructions.) How does a non-bytecode version of Erlang&#x2F;Elixir abstract-machine semantics, achieve these same guarantees? Is there an explicit reduction-counter being carried around in the emitted native code?<p>And <i>also</i>, there is no mention of disadvantages&#x2F;constraints of using this system. It&#x27;s pretty clear that you wouldn&#x27;t be able to do hot reloading or dynamic trace-point insertion without the BEAM there to intermediate it. That&#x27;s fine for some use-cases, but they should explicitly mention the trade-offs and target audience.