I get the feeling that some sections such as "5.4.3. Scheduler inner workings" use terms that many people are not familiar with, such as preemption. That section in particular seems to be background information (it doesn't tell you what you should do, it just tells you what BEAM does under the hood) while "5.4.4 Shared nothing collection" contains some information (that message passing uses copy) that's important to know to be able to reason about the performance of the system.

It might be good to think about what the purpose of such sections is, whether you want to supply extra information to a curious reader with a good background level or whether you want to teach something to a newcomer. At the moment I don't really see a sharp division between "you can skip this if it's too difficult" and "you should read this".

Btw, it's not completely true that big binaries aren't copied, they just aren't copied between local processes. When you get into distributed systems they are copied, so relying on them not to be copied can lead to unpleasant surprises when moving to a distributed setup. Maybe it's useful to make a small note in 5.4.4 that that benefit applies between processes on the same BEAM instance.

Thank you for your comments!

I don't consider section 5.4.3 as a mere extra information for the curious. The aim of this section is to dispel some possible mystique surrounding processes. I think it's beneficial to have a bit more concrete feeling about how processes are internally scheduled, but I tried not to go too deep.

However I do agree that it's a non-actionable section, and I'll consider swapping that one and 5.4.4, so it becomes the last section in the chapter (except for summary).

Good catch about binaries and distributed systems! I'll think about adding a small note here, or mention it in chapter 11 where distributed systems are treated.