I think a major reason to separate the protocol implementation into its own file would be to minimize recompilation of other files that depend on the file that defines the actual module, so you can make independent changes to the protocol definition.
https://hexdocs.pm/mix/Mix.Tasks.Xref.html#module-dependency-types
03juan
3
mau013
OK, I had been playing catch-up with the general group, and had decided to make a write-up once I was caught up.
To give a little bit of my context: I have been using Elixir for the past 8 months coming from a mostly Python + JS background, therefore my ramp up has been as much about learning the language, as to how to write (mostly) functional programs.
To begin learning about Elixir I went through the official documentation and the first 4 Chapters of the 2nd edition of this book. On both accounts I was able to retain the basic elements, especially as I started putting them in practice on simple Phoenix apps.
So coming back to this book has been great, as I can move on from the basics to more intricate elements of Elixir/BEAM.
I will focus on those points that have stood out for me and I wish to fully keep in my mind as I work:
Chapter 2
- Aliases are always atoms (this really clarified some function calls with module references)
- The distinction of when to use the different access functions for Maps:
- %{map | update_key: update_value} when keys are not dynamic, Map.put/3 when they are
- map.key when the keys are atoms and not dynamic
- map[key] along with Map.get/3 when the keys are dynamic (or the keys are not atoms)
- finally Map.fetch/2 when they are dynamic and you want more certainty on whether the key existed or not
- NOTE On Strings I would have added how to use the
<>operator to split a very long string into multiple lines (without inserting the newline char… for the longest time I was constantly forgetting this and googling it
) - IO lists are super interesting… and I have the feeling at some point in my Elixir life they will be relevant (just not sure when or why
)
Chapter 3
- Even binding variables to values is pattern matching (just a special case of it)
- On an
ifstatement if there is noelsebranch and the main branch is not executed thennilis returned - I had completely forgotten about
condbranching - I had completely forgotten about tail recursion
- The capture
&operator can be used to reference an existing function - via module name, function name, arity - or to shorten a lambda definition
Chapter 4
- When the time comes to implement
protocolsI should remember that there is an example here that I can reference
Chapter 5
- BEAM processes are completely isolated and independent from each other, which means they keep their own copy of their context (so any data passed to them will be deep copied)
- A process’ mailbox will operate on FIFO
- A
receiveexpression is blocking unless there is anafterclause - In general be aware that lambda parameters may not be executed where they are declared! The example of using
self()within lambdas was amazing to illustrate this point!
OK, this is all for now.
P.S. I’m already curious how this list will change the third time I go through this book 
5
TimButterfield
Chapter 4 completed.
I enjoyed working through the code and exercises, but have only this note.
Exercise: Deleting an entry
When I first implemented this, I replicated the Map.fetch pattern from update_entry, which validates existence of the id. Then, I looked at the example code which simply calls Map.delete without that check. That generates an error if the id does not exist. Of course, that version would also save time on larger collections. It had me curious as to when I may want to choose one pattern over another, choosing safety vs time savings.
2
sweeneydavidj
Chapter 5 completed. Nice chapter - not too long 
It’s amazing that with just spawn/1, send/2 and receive/1 and little more the amount that can be achieved!
I particularly enjoyed the part about the inner workings of the Scheduler, and the example of the infinite CPU bound loop which was proven not to block other jobs - it reminded me of the excellent talk from Saša from a few years ago…
The Soul of Erlang & Elixir
Looking forward to formalising all this a bit more with GenServer.
5
juhalehtonen
Chapter 5, check 
!
Some points that I found to be excellent reminders about BEAM’s concurrency:
- Data is usually deep copied between processes. This has implications for memory usage considerations and garbage collection simplicity (per-process).
- Data is not always deep copied, but instead can sometimes be copied by reference (binaries >64 bytes, literals, :persistent_term). This can have implications for GC as well (e.g. changes in
:persistent_terms lead to a heavy GC pass) - The execution window within a scheduler before preemption is around 2000 function calls
- Dirty schedulers are kinds of schedulers that can handle long-running CPU-bound tasks (see: dirty NIFs, dirty BIFs, dirty GC)
- Process mailboxes are only limited by available memory (!)
All in all, I loved how this chapter dug deeper into the specifics of BEAM:s concurrency primitives and their use, such as by highlighting things like Erlang emulator flags. These are the things that one doesn’t typically need for day-to-day operations when working with Elixir, but are still very valuable pieces of information know about on occasion. Love the balance of detail with practicality!
How about others – how’s your Elixir In Action adventure going? 
6
TimButterfield
I have completed chapter 5 also. I didn’t make any notes this time, though I noticed many mentions of ‘later chapters’ to cover more details amount different topics. I’m looking forward to getting there to see what they have to say. On a tangent, System.schedulers() reported 12 for my M2 Max MacBook Pro. This matches my 12 cores (8 performance and 4 efficiency). I’m not sure if/how I could specify to use only one type vs the other.
4
bjorng
Erlang Core Team
I have also completed chapter 5.
My only note this time is a suggestion for this part:
Note that this isn’t efficient; you’re using Enum.at/2 to choose a random PID. Because you use a list to keep the processes, and a random lookup is an O(n) operation, selecting a random worker isn’t very performant. You could do better if you used a map with process indexes as keys and PIDs as values. There are also several alternative approaches, such as using a round-robin approach. But for now, let’s stick with this simple implementation.
A simple and efficient way to randomly select a pid is to convert the list of pids to a tuple, and then use elem/2 to extract a random element:
server_pid = elem(tuple_pool, :rand.uniform(100) - 1)
This approach is simpler and should be more efficient than using a map. If the example would be changed to use this approach, the example would still be fairly simple and the note about efficiency would not be needed.
9
harrisi
DidactMacros
I believe Map.delete returns the map passed as an argument, should there be no ID found.
iex(1)> h Map.delete
def delete(map, key)
@spec delete(map(), key()) :: map()
Deletes the entry in map for a specific key.
If the key does not exist, returns map unchanged.
Inlined by the compiler.
## Examples
iex> Map.delete(%{a: 1, b: 2}, :a)
%{b: 2}
iex> Map.delete(%{b: 2}, :a)
%{b: 2}
2
bjorng
Erlang Core Team
I did not consider the initial cost of setting up the pool, because that cost should be irrelevant because the pool is presumably used for many requests. Still, I would expect that creating a tuple should be faster than creating a map.
The reason for my “should” here and in my previous post is that I am generally careful when talking about performance based on my knowledge of the implementation alone (as opposed to having run benchmarks or performed some other measurements). Code that “should” be faster based on how it is implemented is not always faster in practice.
4