Just tweeted about this! This is a learning opportunity I’d regret missing out on 
code-shoily
ranting_rabbit
Hi all!
I have read to the end of the first chapter and I just realized, how well structured the book is. There is a roadmap in the ‘about this book’ section, where the three big parts of the books are introduced and each part as well as each chapter starts with a summary of the content to expect. I like this!
The first chapter until 1.1.1 gives an easy to follow overview of the historical development of Erlang and how its use cases in telecommunication applications resulted in a language specialized in fault tolerance and concurrency.
1.1.2 limited my reading flow a little bit, as the technologies which work together to handle concurrency are described more explicit. In my opinion, the part about how the BEAM, the OS and the hardware interact together would profit from more details or a reference to later chapters here. At the end of this subchapter, I have questions about how the BEAM schedulers utilize CPU cores and threads and OS processes to achieve concurrency and fault tolerance optimization. Even how distribution between instances or computers is archived stays vaguealy.
At this point, I am curious, if this gets clearer from later chapters. I hold a hope, that part 2 lightens things up!
The following subchapters were more easy to follow again. Erlang is compared to microservice architectures and Elixir is introduced as a more elegant language to write code for the beam. Speed and the Ecosystem are listed as disadvantages.
I am looking forward to the next chapters.
6
TimButterfield
I have completed chapter 1 also. It was nice to be reminded of why I was first attracted to Erlang, primarily the fault tolerance and concurrency aspects of it. Though I did not get a chance to create a production system with it, the demo I created using RabbitMQ left a lasting impression and made me eager to try more. Unfortunately, management chose a different technology because it was felt Erlang was too hard to learn. I still disagree.
I knew that WhatsApp was built on Erlang, but had forgotten that Discord was also.
Listing 1.3 mentions use ExActor.GenServer. I don’t recall seeing ExActor used in other places. Are these simplifying libraries not as commonly shared or do folks usually just write their own?
Section 1.3.1 Speed mentions the other languages of C and C++. I always thought of Rust in this context, though it wasn’t mentioned. Is the integration of it not as common?
Should we mention typos here? In 1.1 is this sentence: “It’s acceptable if an occasional request fails due to a bug, but it’s a major problem if the entire system to becomes completely unavailable.” That ‘to’ should be removed.
5
code-shoily
I totally agree that Erlang is not a hard language to learn. In fact I would argue it is easier than Elixir with a handful of syntax policies. However, it gives you a cultural shock (. vs , vs ;, Pascal cased variable and underscored atoms etc), those subtle differences in syntax, closer to English punctuation, takes a toll on you initially as you try to read the code. But to learn it is easy – to get fluency in reading could take slightly longer than say, C or Ruby family of languages.
Exactor was great as a learning tool for me, not that I used it, but I pry opened the source code and learned from it. When I first encountered gen_server it was a little overwhelming to me, wiring my thought process with how behaviours work (and the “dynamism” of it) took more time than I’d like it to, but then when I read this book and saw the mentioning of ExActor, I went to Github, saw the code and went backwards from there, tracing GenServer, it helped me with the concept (I knew about macros so that helped)
Now back to your original question, I think keeping the GenServer explicit helps with folks comprehending your code – whether they come from Elixir or Erlang. It’s just a contract involving some callback and state management. So I can’t speak for the community, but I’d like to stick to a pattern that is committed to the muscle memories of mine and anyone I onboard, and have more examples in the wild. Which is probably a reason I personally wouldn’t use ExActor
Interesting observation on 1.3.1 + Rust though 
5
juhalehtonen
I’ve just finished chapter 1, and I must say, the introduction to the ‘what and why’ behind Erlang and Elixir is excellently presented. Although I feel like the key points Saša discusses are already fairly widely recognized (in the Elixir bubble that I live in, at least!), his articulation of the points is notably direct and clear. In some ways the clarity brought me back to many of the excellent talks Saša has given over the years.
I particularly valued the overview of what Elixir offers, specifically in terms of reducing boilerplate and enhancing the developer experience with tools like Mix and Hex. While I’ve never worked directly on a pure Erlang project, this introduction has definitely sparked my interest to do so! I believe that exploring some Erlang could not only deepen my appreciation for Elixir’s developer experience but also help me understand the inherent simplicity of Erlang as a language. This might even be my key takeaway from this chapter!
Lastly, I really appreciate that the book addresses the limitations of these languages right from the start, rather than avoiding the topic. Understanding both the strengths and limitations of Erlang and Elixir is crucial for making informed decisions. This balanced perspective is important for leveraging the capabilities of Erlang and Elixir while compensating for their weaknesses with other technologies or approaches as needed. Not knowing about the downsides or challenges up front could lead to unpleasant surprises down the road, and so it’s wonderful that this is brought up immediately.
Listing 1.3 mentions use
ExActor.GenServer. I don’t recall seeing ExActor used in other places. Are these simplifying libraries not as commonly shared or do folks usually just write their own?
As for the topic of GenServers and ExActor, it seems that the library is only mentioned to illustrate how much further can be abstracted away with Elixir. Saša himself cautions against actually using the library in this chapter, warning that it obscures the important details of how GenServers work. This point from Saša is further emphasized in the ExActor repository’s README, particularly this commit from years ago . I would have to agree with the sentiment here, as GenServers are such a fundamental building block for many Elixir systems.
6
bjorng
Erlang Core Team
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.
36
AstonJ
*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 
14
paulsullivanjr
I have also finished reading chapter 1. I am a huge fan of this book and own every edition. First as @AstonJ mentioned, a huge thank you to @bjorng and everyone else who has worked on Erlang and the BEAM. You and the team are the reason we exist as a community and we truly are riding on the shoulders of giants.
I really enjoyed how the features of Erlang were described and the high level image of how Erlang concurrency works. Sometimes I think as a community we may be better off communicating Elixir as a concurrent programming language that happens to be functional.
6
code-shoily
If you haven’t already, the Foreword and Preface are not to be missed.
I am being slow this time but I wanted to mention one thing I admire about whatever %-age I am at: Each and every paragraph is arranged in a very meaningful, cohesive way.
On this comment I would like to talk about Table 1-1. The famous table where Erlang is the answer of all your infrastructural aspects versus other languages.
I had a few friends pointed out to me that is it not true and other solutions could potentially be better (ie Redis vs ETS or an Mongo vs Mnesia), but I have a different take to it.
Firstly, if you are Erlang shop, those could take you longer way than others before you make an infrastructural change, and perhaps would keep you in line about dropping to a cache and inventing your own design pattern - since chances are Erlang has some opinion and behaviour around those you might not do it wrong.
Secondly, when you learn Erlang (and Elixir — as we will experience as we go through this book), you don’t experience just the programming language, but the whole enchilada — runtime, process management, distributed and concurrency aspects of it. This feels like opening a book on programming and distributed systems in one go, and for a system to be distributed and stand alone, you need to have things like data store, cache, timer, fsm, dag, event etc built in. So you are 100% armed and ready with Erlang if you open up say, those system design guides, or the classic data intensive book, you can reason about those in code with Beam. When I was interviewing those boring (sorry, big companies) System Design interviews that pluck problems out of Grok book, I could literally see how I could build prototypes of the entire infrastructure only with Erlang or Elixir.
That is what I took from that table and I am grateful for the direction and rationale that one table provided me with.
Sorry for the long post.
9
TimButterfield
I had a similar interpretation of that table. It wasn’t that Erlang is the best at all of those tasks, but that all of those tasks are possible in Erlang. Then, if that prototype or early version proves insufficient, that single portion could be replaced with something else. There is no reason to start with many different technologies when using just Erlang may be sufficient. This also is not rejecting other technologies simply due to a ‘not invented here’ syndrome. For example, if a queuing mechanism is needed, RabbitMQ may be an option and would still be implemented in Erlang.
7