Elixir In Action Book Club!

Chat / Discussions
,
1

Welcome to our Elixir In Action Book Club! :048:

This book was recently released in its third edition so we thought it was about time we had a book club on it! It is being led by @code-shoily and @juhalehtonen and the author of the book, @sasajuric, will also be dropping in from time to time - so if you have any questions it could be a great way to interact with the author!

Here’s the full list of participants:

There’s no strict schedule but we encourage everyone to post at least once per chapter, and please remember that while criticism is fine, please be kind - book authors are our friends and members of the community too :blush:

Everyone else is also welcome to join the book club or to comment on anything you find interesting. For anyone who wants to join or purchase the book we’ve also got a limited-time 45% off coupon - simply use elixclub24 at checkout over at manning.com! :023:

20 Likes
2

Super happy to be here. Looking forward to discuss and learn from y’all. Apologies in advance for the upcoming stream of (friendly) reminders :wink:

I will mostly be reading on Fri/Sat and posting on Wednesdays!

6 Likes
3

I loaded the book on to my phone last night and read the excellent foreword by @FrancescoC, where he says when he asked José what problem he was trying to solve José said that he wanted to bring the power of Erlang to other communities. Francesco goes on to say he had put the same question to many other language creators but José was the first to say his focus was on the adoption of ideas, semantics, and run-time (of the extremely powerful Erlang) and he did it by approaching the problem with a different syntax, tools, and development approach.

In more simpler terms (and something many of us have been saying on places like the forum) his goal was to essentially make the power of Erlang as accessible as possible to people who have learnt or have become accustomed to what some might consider ‘modern’ languages and frameworks, such as Ruby and Rails.

I’m glad Francesco got it directly out of the horses mouth and when people ask this question in future I will point them to this post! :smiley:

PS, if anyone is interested here is my review of the original edition of this book: Elixir In Action (Manning) - #2 by AstonJ

7 Likes
4

Hi all! :wave: Looking forward to hearing from everyone on their journey through Elixir In Action!

The way I’m approaching the book’s latest edition is bound to be different from the way I approached Elixir books many years ago, back when I was just getting started with Elixir.

Nevertheless, I’m certain there will be much to learn from the book, alongside many great reminders of the core truths of the platform. I’ll be sure to document my journey through the chapters here in the thread!

Just like the foreword from Francesco Cesarini and the preface by Saša Jurić point out, the fundamentals of OTP are not only the stable foundation upon which Elixir builds upon, but also one of the key differentiators and reasons why Elixir (and the broader Erlang ecosystem) is different from many other languages. Truly understanding the OTP way of building software is what truly unlocks Elixir’s full potential, and the truths about that never go out of fashion :wink:

What are you looking forward to gaining from the book? :slightly_smiling_face:

5 Likes
5

I had read the first version of this book when I was learning Elixir, I was a reviewer for the second version of this book. For this third version I have a different thing in mind.

I have been hearing a lot that “Elixir is a difficult language for beginners” - I vocally disagree with that. One of my things to do this year was to produce some beginner friendly Elixir texts.

My goal for reading this third incarnation of this book would be to revisit Elixir with a pedagogical point of view. And chatting with like minded folks and hearing their opinions and learning from their experiences - chapter by chapter.

Aside from that, this is one of the three books that helped me become a better programmer so I will be party to a book club even when it is for the 10th edition.

5 Likes
6

What are the other two?

3 Likes
7

One is “Joy of Clojure” the other one is actually a whole website but the book Domain Modeling made Functional is a great book and one I read multiple times.

Update: I no longer work with Clojure and I was never really an F# dev but I used concepts of those to enrich my reasoning about pieces of codes. Also, all these resources take a very pragmatic approach at describing things without being too academic, that’s a style I really enjoy reading.

3 Likes
8

I partially read the first edition of this book and am taking the opportunity to try and make it all the way through now that the third edition is out. I struggle to finish books like this, even when they are as well written and useful as EiA. My hope is that by joining a book club I can keep myself accountable to push through when other shiny things are tempting me away :grin:

As for what I hope to learn, I’m keen to deepen my understanding of the concurrent side of Elixir and learn more about maintaining production BEAM applications.

4 Likes
9

I have both prior versions of this book and have worked a little with the Erlang on which Elixir is based. It will be interesting to see what additional ideas I can glean from the book this time around. Hopefully, the regular pacing of a book club reading and the discussions here lead to deeper understanding.

This is my first book club here. The opening post encouraged posting once per chapter. But, what is the expected pacing for chapters? Is that one chapter per week or some other faster or slower frequency? I want to make sure my expectations are aligned.

2 Likes
10

@code-shoily has said he’ll be posting weekly updates but there are no hard or fast rules Tim, just go at your own pace and post your thoughts or get involved with discussions as and when you can :smiley:

4 Likes
11

The mighty @bjorng will be joining as well! :003:

I’m sure I won’t be the only one interested in hearing his thoughts on Elixir while working his way through the book :star_struck:

7 Likes
12

Just tweeted about this! This is a learning opportunity I’d regret missing out on :slight_smile:

1 Like
13

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 Likes
14

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 Likes
15

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 :thinking:

4 Likes
16

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 :slight_smile:. I would have to agree with the sentiment here, as GenServers are such a fundamental building block for many Elixir systems.

6 Likes
17

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. :003:

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. :slight_smile:

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.

28 Likes
18

*Reads the rest of your post…

You already have Björn :blush:

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 :heart: :purple_heart:

11 Likes
19

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 Likes
20

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.

7 Likes