Having the read the first chapter of the book, I don’t have much to say. I think it is a really good introduction to the BEAM, Erlang, and Elixir, with just the right amount of details.

Thanks for that introduction! Now I must try to live up to it.

I will take this opportunity to introduce myself and my experience of programming in Elixir.

I wrote my first Elixir programs in December of 2018. José posted a few screencasts showing the puzzles in Advent of Code. I immediately decided that I wanted to solve the puzzles while learning Elixir. It turned out that the puzzles themselves was the hardest part. Learning Elixir (enough to solve the puzzles) was easy. I read the crash course for Erlang developers to get going and then I learned more by looking at the other solutions in the forum, and especially at @sasajuric’s elegant solutions using Enum, Stream, and the pipe operator.

Here is a little about myself and my work in the OTP team.

I am the Björn in “Bogdan/Björn’s Erlang Abstract Machine (BEAM)” mentioned in the book.

I joined the OTP team at the end of 1996, and the first Erlang/OTP release in which some of my code was included was OTP R1D. A few years later, when the inventor of BEAM, Bogumil “Bogdan” Hausman, left Ericsson, I became the main developer responsible for BEAM.

To put that in context, I’ll need to explain how the meaning of the word “BEAM” has changed. Nowadays, the word “BEAM” (at least in common speech) seems to have evolved to mean the entire runtime system for Erlang. That it is also the sense used in the book.

At that time (OTP R1 through OTP R6 R5), there existed two Erlang implementations side by side: Joe Armstrong’s original JAM (Joe’s Abstract Machine) and BEAM. They shared the source of the runtime system (scheduler, BIFs, garbage collector, ETS, drivers, and so on).

“BEAM” at that time only referred to the part of the runtime system that executed the BEAM instructions. That is the part that I spent many years on improving and maturing so that it could replace JAM completely. My own invention in that area is the loader of BEAM code.

My blog post A Brief History of the BEAM Compiler goes beyond its title, giving more details on the early Erlang implementations in general, and BEAM and my involvement in its development in particular.

Returning to the book, the only thing that I think could have been added and is perhaps worth adding in the fourth edition, is a mention of the JIT (Just-In-Time compiler) in the Speed section. As written in the book, we in the OTP team do try to keep the performance as predictable as possible, but we also try to improve the raw performance with the goal to make it less frequently necessary to use libraries or programs implemented in C/C++/Rust. But my opinion in that matter is hardly unbiased.

Perhaps another language feature is worth emphasising: the bit syntax/binary syntax. It makes parsing of binary protocols much easier than in most other languages. For example, the PER encoding rules for ASN.1 is a nightmare to implement in other languages, but quite easy to implement in Erlang/Elixir using the bit syntax.

Hi everyone

It’s great seeing so many people here! I’m looking forward to the fun discussions. I’ll try to keep up as much as possible, but obviously I can’t address every comment & question. If you feel I’ve glossed over or skipped some important point or question, hit me a DM.

This was listed as an example of what can be done with macros, but in general, as the author of ExActor, I don’t recommend using it I shall try to find a better example for the next edition.

People are using Rust together with Erlang/Elixir. I think Rustler is a popular choice (Rustler — Rustler v0.38.0). I didn’t think about explicitly mentioning it, but I’ll reconsider this for the next edition.

Ideally those would be reported at the official book page on manning, so they can be marked as correct, and fixed with the next update. But if it’s too much trouble, you can report it here, and I’ll see about transferring them over there.

Suddenly I’m starting to feel slightly nervous

I remember that! It was so much fun comparing solutions!

Great point, this should be mentioned. The 1st edition was written way back when there was no JIT, and I somehow missed this opportunity during the update. I’ll see about fixing it in the 4th.

Fun fact: the first drafts used the term EVM (Erlang Virtual Machine). But after discussing it with a few folks, I’ve changed it, because it wasn’t really used in the community, while BEAM seemed to be more popular than ERTS. I wonder if at this point the ship has sailed (for which I’m probably partially guilty myself)?

This is the correct interpretation. Also, the table tells the true story, not some hypothetical. Having worked on both systems from day 1, I was confident that the 1st one could be vastly simplified with Erlang. But yeah, I’m not suggesting that the Erlang solutions can always replace the mentioned products.

*Reads the rest of your post..

You already have Björn

Would also like to take this opportunity to thank you and everyone else who has worked or works on Erlang and the BEAM - Elixir and this community only managed to get to where it has because of you and all your hard work spanning decades