A brief introduction to BEAM

https://blog.erlang.org/a-brief-BEAM-primer/

by codeadict • 6 years ago

224 35 6 years ago

blog.erlang.org

phoe-krk2• 6 years ago

In the exception example, there is a line saying:

    {'try',{y,0},{f,13}}.

Why is the symbol `try` quoted here? Does it need to, if its name is all lowercase?

rdtsc2• 6 years ago

Because 'try' is also a keyword in Erlang. The other symbols like that without the quotes are atoms (http://erlang.org/doc/reference_manual/data_types.html#atom).

So to have an atom named after a keyword we'd have to add single quotes around it.

phoe-krk2• 6 years ago

Yes, got it - thank you for the response.

dnautics5• 6 years ago

well, this is pretty timely. I have been peeking at some of the opcodes in the BEAM and some of this stuff I had gotten wrong; since there isn't AFAICT easy-to-find documentation on how this works. Does anyone know of other resources along these lines?

RobertKerans• 6 years ago

https://github.com/happi/theBeamBook

hkgumbs• 6 years ago

I'd highly recommend "The Beam Book" by Erik Stenman: https://blog.stenmans.org/theBeamBook/

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

dnautics5• 6 years ago

I'm familiar with the beam book but iirc it's incomplete, in particular in terms of what OP speaks of :|

adenozine• 6 years ago

I wish there was a python implementation that ran on BEAM.

ch4s32• 6 years ago

Luerl is probably the closest thing in terms of semantics, but Elixir might feel right in terms of Syntax. Actually running Python on the BEAM would probably be pretty challenging based on what I've read about the GraalVM python efforts.

blixtsnabb• 6 years ago

There is efene (https://efene.org) which claims to embrace the ZEN of python.

macintux• 6 years ago

Here’s a reasonably exhaustive list of languages that do:

https://gist.github.com/macintux/6349828#alternative-languag...

josefrichter• 6 years ago

go for elixir. the differences compared to python are minuscule.

freehunter• 6 years ago

Python and Elixir could not be further from each other. Just for starters, Python is OOP and Elixir is FP, which is a far bigger difference than you seem to imply. Elixir is compiled while Python is interpreted. Python has absolutely incredible community package support while Elixir is much more niche. It's hardly miniscule. It's a completely different way of programming.

rdtsc2• 6 years ago

The JIT in OTP 24 mentioned at the top was discussed in https://news.ycombinator.com/item?id=24441841

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.

---

hinkley• 6 years ago

I’ve heard that errors in native code called via FFI in BEAM code is the primary place where the runtime can behave uncharacteristically. I haven’t seen anyone in the community describe it this way but it has the feel of undefined behavior to it.

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.

rozap• 6 years ago

It's super exciting, but the JIT in its current form doesn't offer the kind of speedup that something like FFI into Rust or C provides. Also there are lots of great libraries in the Rust/C ecosystems that sometimes you need. Fortunately FFI is not hard, and with the relatively recent addition of dirty schedulers and with the Rustler library, it doesn't block the schedulers and it is safe, which were the two biggest issues.

toast0• 6 years ago

When you call into native code, you're explicitly opening the door to letting whatever happen happen. It's not undefined, it's a clearly defined escape hatch to do whatever. There's rules to follow, but it's the honor system, BEAM doesn't care if you do or not, but you'll have to live with the decisions you make.

pjmlp• 6 years ago

Calling into native is by definition the "unsafe" code block of managed languages, even if you are calling into Rust, unless you explicitly validated the code of the dependency being loaded.

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.

imtringued2• 6 years ago

There are two problems. Firstly, you don't want a crash in C code to take down your reliable Erlang VM. Secondly, external code has to play nice with the reduction counter and Rust doesn't offer benefits over other languages in this regard.

alberth• 6 years ago

Has anyone seen benchmarks of the new JIT vs HiPE?

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?

pselbert• 6 years ago

According to the recent Thinking Elixir podcast [0] the performance is comparable. They specifically cite the performance of dialyzer, which typically runs through HiPE, as being just as fast with the new JIT.

From what I recall HiPE isn't widely used and will be (may be?) removed.

[0] https://thinkingelixir.com/podcast-episodes/017-jit-compiler...

PrinceKropotkin• 6 years ago

What kind of static analysis is available for BEAM programs?

rehemiau• 6 years ago

Take a look at Xref and Dialyzer

dnautics5• 6 years ago

I'm working on one for elixir: https://github.com/ityonemo/selectrix

waynesonfire• 6 years ago

what's the recommended IDE for erlang dev? I've tried getting emacs setup but boy it's a struggle. I tried following this beast of a guide with questionable results,

https://www.lambdacat.com/post-modern-emacs-setup-for-erlang...

simscitizen• 6 years ago

There is an Erlang plugin for IntelliJ which is...ok.

silly-silly2• 6 years ago

What is the struggle part ?

silly-silly2• 6 years ago

I ask, because maybe I could/should write up something for /r/erlang,

rapsey• 6 years ago

Vscode has two lsp plugins. I find pgourlains version to be better

rkangel• 6 years ago

I was surprised to read that the BEAM has no concept of processes.

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).

A brief introduction to BEAM

Related Stories