In what way is process based parallelism strictly worse? On Linux a process and a thread in the kernel are both the same thing. The main difference between the two is that threads share memory by default whereas a process would need to explicitly mmap a chunk of memory to share with another process. This means that with threads you get to save RAM because of application code not having to take up more space (except memory is effectively deduplicated already because those are read only blocks) and with threads you have to explicitly guard against trampling over each others’ memory, whereas with processes it’s safety by default and you have to make an explicit choice to share memory, limiting the number of places you can forget to add or check a lock. I will grant you that languages where standard libraries by default shoehorn you into using sockets to communicate between processes do by default introduce more overhead than just using threads. But any serious language will have at least one queue implementation that’s based on very fast primitives over shared virtual memory. I say this as someone whose done projects using a number of different types of parallelism, including process and thread, and can find strengths for all these. I just think treatment of process based parallelism is undeserved: it can be very efficient if done well, and no worse than a lot of the other methods for a large number of use cases.