Hacker News Reader

Whether memory is shared by default (threads) or explicitly (processes) is a little bit of a red herring. The thing that makes parallelized designs hard happens at a higher level: it's that whatever your shared resources are (files, databases, shared memory, in-core databases hanging off message listeners, etc), you have to find a design that allows things to be shared and correct, and that's a hard balance to strike.

View on HN

You are assuming shared memory as the communication medium. When using processes, you can use sockets for IPC for example. The advantage is that the application can then scale beyond a single system with no change - something that's impossible to do with threads. It's easier to implement and more scalable. Far from a red herring, the persistent focus on threads for concurrency imposes limitations that are unnecessary in modern systems, and slows development.

Pretty sure you and I just said the same thing, though let me just add that just because you hang something off a socket doesn't mean your design can't serialize around it. Having 100 concurrent workers doesn't help if all of them are just lining up waiting for another program to answer their messages.

Of course, this is the exact same problem you have when you try to make a naive design concurrent by wrapping all the global variables in mutexes.

Reply on news.ycombinator.com