IIUC, this architectural pattern can be seen in a lot of different places: 1. Actor Model (ref: Erlang) or Communicating Sequential Processes (ref: Golang) as

IIUC, this architectural pattern can be seen in a lot of different places: 1. Actor Model (ref: Erlang) or Communicating Sequential Processes (ref: Golang) as someone already mentioned in the comments. 2. Distributed replicated logs (ref: Kafka) acting as shared vocabulary for multiple data sources and sinks 3. D-Bus (for IPC b/w Linux processes) 4. Or any event-based system (ref: Node.js) So there's definitely two separate threads (no pun intended) of discussion here: 1. The BP idea 2. The implementation (a la B-threads) The BP idea's benefits can be seen, to an extent, in all the different models described above. But they also suffer from the same problems as any BP implementation: 1. Double negation[1] (as someone already mentioned in the comments) 2. If a specification change touches multiple "events" (aka shared vocabulary), it'll need refactoring across code organization units (eg. actors in Actor Model, B-theads in BP, functions/callbacks in Event-based systems, etc.) - which brings us back to the original problem of the human mind having to think of disparate execution paths to bring about spec changes in software. [1] https://news.ycombinator.com/item?id=20560001 https://news.ycombinator.com/item?id=20560001