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 Likes
Just finished Chapter 1. As someone coming from a more typical background (web servers in Java, Python, etc.) the explanations of the BEAM and history of Erlang were very helpful to put everything in context for an Elixir newbie.
Favorite quote:
“The goal of the platform isn’t to squeeze out as many requests per second as possible but to keep performance as predictable and within limits as possible.”
7 Likes
Hi all, I have been a long time haven’t seriously checked with elixir since my last job.
hopefully can leave some time to read the book and put the review here every week.
4 Likes
Hey all,
Ruby/Rails dev here with recent interest in Elixir. I’ve played around with Elixir/Phoenix extremely lightly with a couple tutorials, but will essentially be coming into this from the perspective of someone with no real in-depth knowledge in Elixir.
I already own EIA and it’s up next on my book list. I’ll be joining you all very shortly and wanted to send a quick hello.
Cheers,
Mike
5 Likes
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.32.1). 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.
15 Likes
Hi, thanks for setting this up!
I’m a little late to the party but yesterday I got the latest edition and read until the end of the first chapter. I read the earlier editions quite some time ago, but this is such a great book that I couldn’t let this opportunity pass. I really enjoyed the first chapter, in particular I love how Sasa tells the story from the Erlang point of view - it makes me feel like we’re getting the full, deeper version of the story.
4 Likes
I will try adding some comments when I finish one chapter:
Chapter 1:
Mostly the same as the previous editions - talk about Erlang highly availability, the difficulty part to use Erlang and the motivation to use Elixir, and a general comparison to other programming languages like Ruby and C/C++.
The content as the first introductory chapter is very concise and accurate. The only part I will suggest is - It is probably a good idea to compare with Golang, a direct competitive to Elixir.
Chapter 2:
Basically the same draft as the old editions. This chapter is like a short usage guide on Elixir and the shell. I like it very much. It is short enough and covers most stuff you need to write a basic Elixir program.
Also, I am happy to see a book that it does not try to cover all the very basic stuff like data types nor boring small projects IMMEDIATELY.
2 Likes
First, what a great dedication page. I love that. 
Chapter 1
Background Info: I enjoyed the background and intro into Erlang. It wasn’t too extensive, and it was straight to the point regarding the pros, cons and reasons why many choose Elixir vs programming in Erlang.
Table 1.1 Comparison: I know this is just a top-level example comparing a couple different setups, but I don’t think a single person will glance at this and complain about the potential ease of Server B. I’m looking forward to learning more about this.
It’s good to know we can still use all the power of Erlang with the seemingly more enjoyable syntax/dev experience of Elixir.
That’s it for now. Looking forward to the next chapters.
3 Likes
Joining in! I am a few chapters in already, but glad I found this.
Coming from ruby on rails, I had to re-read and practice a few chapters to get my head around it.
4 Likes
Congratulations to the author and the entire team.
I’m a ruby on rails dev with 12 years of experience and I’ve worked with Elixir for about 5 years. I read the first edition and am reading the third edition of Elixir in Action. Congratulations. I want to get back to working with Elixir is a great book that helps me stay up to date.
4 Likes
Awesome that you’re doing a book club for this! I’ve only had digital copies of previous Elixir in Action releases, this time I decided it’s time to have it in print for a better reading experience.
However, it was not easy to swallow the $18 shipping cost in Europe from Manning.
Anyway, can’t wait to receive it
6 Likes
That’s me up to the end of Chapter 1. It’s as great an intro as I remember from my first read through. I agree with @ranting_rabbit that it has left me hungry for more details on scheduling and distribution 
The thing that stuck with me on this read through were the lines
Furthermore, I/O operations are internally delegated to separate threads, or a kernel-poll service of the underlying OS is used, if available. This means that any process that waits for an I/O operation to finish won’t block the execution of other processes.
Looking forward to getting stuck into Chapter 2!
5 Likes
Just finished reading Chapter 2 this morning. I think the chapter offers a great overview on the basic building blocks of the language and a gentle introduction to how to write and run Elixir (and Erlang!) code.
I’m glad the book takes the time to point out how Elixir & Erlang don’t actually have booleans at all, and true and false (and nil) are just atoms in disguise.I still remember the first time I learned this, and how it made something click in my head about the intersection between Elixir and Erlang.
(As an aside, this point about booleans made me wonder what (probably none!) implications this has on the implementation details of set-theoretic types that are in the works for Elixir. I recall the papers speaking about booleans, but I presume the word is used in the exact same way we speak of booleans in Elixir today).
I’m a fan of the book taking the time to explain lists and visualizing the recursive nature of them. Back when I was first learning Elixir, I recall that it took me a good while to get a grasp on the way lists worked, and I’m sure the effort put into the book here will save some future learner a bunch of time
I appreciated the introductions to bitstrings and IO lists and felt like it was a nice refresher on the topic. Despite being familiar with them on a theoretical level, I have very rarely directly used either of them even after my ~8 years spent with Elixir!
When I saw the title of Macros, I was slightly surprised they were being introduced at this stage as well. However, I feel Saša took the absolute right approach here by simply pointing out their general idea and value proposition without trying to teach how to use them.It’s wonderful to know macros exist and what they can do, but as Saša points out, learning them thoroughly takes a whole book
All in all, I’m happy to say that the chapter gave me food for thought despite having worked with the language for a while already. How about you – what caught your attention in Chapter 2?
4 Likes
I have finished chapter 2 also. It reminded me how much I had forgotten.
I like how it often linked to the docs for certain parts in case you wanted a bit deeper dive into something specific.
Here are a few things that stood out.
In 2.4.2 is this example:
:“an atom with spaces”
I don’t recall seeing this usage actually being used. Is there a practical reason why this is useful in some scenarios?
In 2.4.8, sigils for binary strings mentions this difference:
~s"Interpolated #{3 + 0.14}"
~S"Not interpolated #{3 + 0.14}"
The charlist sigil does not mention this difference, though it also works.
~c"Interpolated #{3 + 0.14}"
~C"Not interpolated #{3 + 0.14}"
Mentioned for completeness. 
I’m not sure when this would be needed for lists of individual characters as the interpolation changes which characters are available. Perhaps it could be useful when combined with binary strings as in the examples of 2.4.12 IO lists. By comparison, trying to use the date and time sigils (~D, ~T, and ~U) as lowercase throws an error.
When looking at the comparison operators of table 2.1, I had to look at the second row for a bit. The descriptions for >= and <= are swapped to have a reversed order in the description than for the operators. It’s not a big deal, but had me make sure I wasn’t missing something.
Overall, this chapter has me eager to begin using it in subsequent chapters.
2 Likes
I have not yet read chapter 2, but it’s more to the point that :"" lets you use any character in an atom. This is actually used all the time behind the scenes when working with aliases. When I say “alias” I mean atoms that start with a capital letter.
Any time you do defmodule Foo, do: () you’re actually creating the atom: :"Elixir.Foo", so the very character Elixir uses as a delimiter isn’t valid in the “regular” atom syntax!
5 Likes
Wanted to jump in to reinforce for anyone reading this book for the first time, this really is one of the best programming language books I have ever read. Saša’s communication (written and verbal) is clear and concise. Seriously, you can’t go better than this book.
That being said, I’ve read through most of the third edition and the second edition before. I am trying to catch up with the book club right now. Love seeing Bjorn here as well. I think having both Saša and Bjorn both in this thread is a testament to the community and is perhaps one of its strongest and most understated assets. You guys (gals, and nonbinary pals - everyone on the forum) rock.
6 Likes
I’m a bit late to the party, I suppose! Just finished chapter 1. I started learning Elixir earnestly a couple weeks ago coming from Erlang.
So far I’m enjoying the book quite a bit! The introductory portion on Erlang was much easier to follow than the resources I used to learn Erlang originally. I wish I’d had this as my primer back then. I didn’t really get any new information out of chapter one, but it is strikingly well-presented so far. I will include a little bit my new-to-Elixir thoughts as well though–something I would have gotten out of the chapter if I hadn’t read another intro book first.
Elixir’s pipe operator is very good. I spent a Saturday in college looking at several languages which implement the three basic functors and was quite dismayed to learn that Javascript’s dot-methods were more readable than most functional languages’ composition features. Javascript’s functors only count because of how… javascript it’s type system is, and that OOP-style syntax doesn’t quite track with what’s going on under the hood in a functional language. It’s hard to build things that are intuitively understandable and semantically accurate to the machine behaviors! Maybe I’m just easily excitable, but something like the pipe operator that achieves that is just lovely. Seems hard to go back!
7 Likes
I read the wrong edition for Chapter 2 
I didn’t realize I hadn’t downloaded the third edition on my tablet. Well my review for chapter 2 will be a rather diff based one since I just read second edition!
2 Likes
I have now read chapter 2. Overall it is an excellent chapter providing a good introduction to the building blocks of Elixir. I like that it is generally made clear what Elixir types are inherited from Erlang and which are not.
I found a few minor inaccuracies, and I have a few suggestions for improvements.
In 2.4.1 Numbers:
There is no upper limit on an integer’s size
There is an upper limit, but it is not documented anywhere as far as I know. Perhaps better to say that there is no upper limit for practical purposes. The current limit is more than one million decimal digits. It used to be higher. (For some background information about the current limit, see Integer arithmetic improvements and the linked pull requests.)
Later in the same section, it is said:
… a float occupies either 32 or 64 bits, depending on the build architecture of the virtual machine.
The float value itself is always 64 bits (a double in C) regardless of the build architecture. But then there is some overhead that is more significant than for an integer.
On a 64-bit system, a small integer having up to 60 bits is stored in a single word. The four least significant bits are reserved for a tag to distinguish small integers from other Erlang terms.
A float needs three words (on a 64-bit system). One word is a tagged pointer to two words on the heap. The first of those two word is a header word (to distinguish floats from other heap objects such as tuples or maps), and the second word is the float value itself.
(As an optimization, in a sequence of floating point operations, BEAM can store floats in special float registers. For example, see this matrix multiplication function. The is_float/1 guard tests are there to ensure that the float registers are used; without them the performance would be much worse.)
In NIL AND TRUTHY VALUES (in 2.4.2 Atoms), the nil atom is mentioned. Since all other data types described in this section are also Erlang data types, I think that it should be mentioned that the atom nil has no special meaning in Erlang, and that the &&, ||, and ! operators don’t exist in Erlang.
Also, in 2.4.11 Higher-level types, it is mentioned that “The aforementioned built-in types are inherited from the Erlang world”. I suggest that you point out that nil is the exception.
In 2.4.4 Lists, it is said that " In Erlang, lists are used to manage dynamic, variable-sized collections of data". That is correct, but perhaps you meant to say “In Elixir, …” or possibly “In Erlang and Elixir, …”
In 2.4.6 Maps, it is mentioned that squares[2] can be used to retrieve a value from a map. As I understand it, this is a less performant way to retrieve a value from a map than using the Map module. Because of that and because of the many ways maps can be accessed, already making maps confusing, perhaps it would be better to mention this way at the end of the Maps section?
In 2.4.7 Binaries and bitstrings, there is the following example:
iex(5)> <<257::16>>
<<1, 1>>
I think that it would be better to use an integer that will show whether it will be stored in big or little endian order. For example:
iex(5)> <<260::16>>
<<1, 4>>
Even if big endian or little endian is not mentioned in the text, I think it would be nice to use an example from which anyone interested could deduce that the default order is big endian.
In 2.4.12 IO lists, it is stated that “Lists usually aren’t effective in this case because appending to a list is an O(n) operation”. I think that the word “effective” should be replaced with “efficient”. “Effective” means producing a result that is wanted or intended, while “efficient” means capable of producing a desired result without wasting materials, time, or energy.
12 Likes
Chapter 2:
Whew. This chapter for me felt extremely long. I was jotting down a multitude of notes, which extended the time, but it was a lot of info. Great info, just a lot of it.
I noticed many similarities/familiarities with my current knowledge from Ruby, which makes some of this very easy to pick up and understand. There are also a lot of newer concepts for me. Some random notes:
-
Function arguments with default values generate multiple functions of the same name with different arities.This is pretty cool and something I had not thought of. -
I had seen function variables called with something like
square.(5)in passing, but being new to Elixir hadn’t looked into why the.was used in the code. Makes perfect sense now and it’s nice to have that clarification up front in the early stages of learning. -
Also nice to see the capture operator
&to make code more concise. I frequently use something similar in Ruby with Procs like[1,2,3].map(&:to_s). Pretty easy to translate that into
Enum.map([1, 2, 3], &Integer.to_string/1)(I think that’s the most concise?) -
All the main data types make sense so far, it will just take some practice and time to get used to all the new syntax and functions available.
I’m glad I took a bit longer to take notes throughout this chapter even though I wanted to breeze through it. I’m excited to be done with the basics here and move on to Chapter 3 - Pattern matching is still something really new to me and it hasn’t fully clicked yet when I’ve glanced at this previously. It will be nice to solidify my thinking/knowledge around it.
Hope everyone is enjoying the book!
7 Likes
