Totally agree with you. Multithreaded programming is never easy, neither in Go nor in any other multithreaded language. Erlang is probably the safest because of

Totally agree with you. Multithreaded programming is never easy, neither in Go nor in any other multithreaded language. Erlang is probably the safest because of only immutable data, but you can still deadlock there. The Observer pattern which is shown here can be especially tricky. Once you register a callback for an event you don't necessarily know from which thread the callback will be called. Some libraries will fire callbacks from a worker thread, other might marshal them to some kind of main thread, etc. If callbacks are fired from multiple threads then event ordering won't be guaranteed and you probably need locking in the receiver (be aware of deadlocks). The next tricky thing is cancellation/unsubscription. In most multithreaded implementations you might still get notifications shortly after unsubscribe during special timing conditions if the thread that fires the notification has not yet processed the unsubscription (or operates on a copied and outdated subscriber list). A singlethreaded runtime (like node) makes reasoning around this much easier. And you need a lot of less extra safeguarding code to care for these race conditions.