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