It's very easy to create an event-driven program that is effectively a larger program implemented in terms of "come-from". The decoupling provided by eventing i

It's very easy to create an event-driven program that is effectively a larger program implemented in terms of "come-from". The decoupling provided by eventing is often illusory; if there's a higher-level semantic that's supposed to be implemented in terms of the outcome of coordinated event handlers, then the dependencies still exist - they're just implicit. If event-handlers are genuinely decoupled from one another, and there isn't a higher-level state machine that's being driven by events, then it can be an excellent way to structure logic. Events-as-deltas that are durably stored and can be reliably replayed is another fine way to go for a system with checkpoints, auditing, history, rollback, time-series reporting and similar requirements. But like the article says, code will be much simpler if it deals with an eternal present and the calculation and application of the deltas is centralized in code that doesn't change often. There's an isomorphism between building a bigger program out of event handlers, and distributed programming. Distributed programming is known to be difficult, and doing it at the message send level is IMO too low a level - one should build more expressive and composable primitives and work at a higher level. That's if it's warranted at all.