A brief introduction to BEAM(blog.erlang.org) |
A brief introduction to BEAM(blog.erlang.org) |
I am looking forward to more blog posts about it.
A few interesting snippets from the PR comments from it:
---
[...] number of Estones as computed by the estone benchmark suite becomes about 50% larger, meaning about 50% more work can be done during the same time period. Individual benchmarks within the estone benchmark suite vary from a 170% increase (pattern matching) to no change at all (huge messages)
[...] If we run the JSON benchmarks found in the Poison or Jason, BeamAsm achieves anything from 30% to 130% increase (average at about 70%) in the number of iterations per second for all Erlang/Elixir implementations.
---
There’s apparently some heightened interest in Rust for these purposes because its guarantees offer some additional robustness here.
But having JIT for the BEAM changes the calculus of whether it’s worth maintaining your code in two languages for a speed improvement that comes with additional liabilities. It will be interesting to see what libraries and tools become pure as the JIT covers more territory.
There are zero guarantees that the Rust code is correct (free of logical errors), or makes use of unsafe in ways that are properly correct, and given cargo, you also need to validate every dependency that is brought into the shared library.
The only guarantees are that it will abort/panic on bounds checking, numeric overflows and whatever unsafe code it has (regardless of its correctness), is explicitly marked in unsafe code blocks.
A few years ago, I spent my free time building a Haskell BEAM codegen library, and that was by far the best resource I found. I noted some other projects that helped me understand things here: https://github.com/kofigumbs/codec-beam#acknowledgements
I assume that the BEAM has some primitives to do with reduction counting and pre-emption that can be used to implement the full erlang process, but the BEAM book (https://blog.stenmans.org/theBeamBook/#_concurrency_parallel...) isn't very clear which bits are in the C code (the BEAM) or the Erlang code (the ERTS).
{'try',{y,0},{f,13}}.
So to have an atom named after a keyword we'd have to add single quotes around it.
Everything I’ve read is comparing the JIT to the interpreter, but HiPE itself is faster than the interpreter. So is JIT faster than HiPE?
From what I recall HiPE isn't widely used and will be (may be?) removed.
[0]: https://thinkingelixir.com/podcast-episodes/017-jit-compiler...
https://gist.github.com/macintux/6349828#alternative-languag...
https://www.lambdacat.com/post-modern-emacs-setup-for-erlang...
What elixir doesn't have is pass-by-reference. Which, imho, is a huge win, unless you are going matrix math.
When people talk about how similar are OOP and FP languages they miss the elephant in the room - immutability.
> When people talk about how similar are OOP and FP languages they miss the elephant in the room - immutability.
>> What elixir doesn't have is pass-by-reference
But immutability is not INHERENT to the FP style. In the strictest sense BEAM languages are not immutable, because message-passing is not state-safe, and there's also the Process library (and NIFs), but practically they are. Julia is also a very powerful FP language that isn't immutable by default, and Swift is an OO-ish? is it OO? language that is pass-by-value by default.