Comment by weatherlight
15 hours ago
The BEAM virtual machine. Its has lightweight isolated processes, message passing, supervisors, hot-ish runtime introspection, and fault containment are not libraries bolted on later. They are the substrate. not an after thought.
if you are build an app that needs the following: + many concurrent users + real-time UI + background jobs + workflows + stateful sessions + distributed events + failure isolation + “this thing should keep running for months”
You're going to want the thing built on the BEAM.
But it doesn't have neither AOT nor JIT.
I believe BEAM bytecode is now JIT-ed.
EDIT: It is, since OTP 24 was released in 2021:
https://www.erlang.org/downloads/24
> The BeamAsm JIT-compiler has been added to Erlang/OTP and will give a significant performance boost for many applications. The JIT-compiler is enabled by default on most x86 64-bit platforms that have a C++ compiler that can compile C++17.
elixir/erlang gets compiled into beam byte code. It's a vm. why does this matter..
It's an interpreted byte code run (interpreted) by BEAM. Not a native binary run by CPU.
But apparently BeamAsm JIT solves the issue? As mentioned in the sibling comment.
What about https://www.erlang.org/doc/apps/erts/beamasm.html