Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


But why does a particular execution model matter?


Raw performance.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: