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.
> 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.
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.
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.
An AOT compiler with better optimizations will run circles around BEAM on benchmarks.