They do, but I think also that possibly every user of such a framework has at least once created a concurrency issue once in their life. All of these the issues

They do, but I think also that possibly every user of such a framework has at least once created a concurrency issue once in their life. All of these the issues below are things I have seen (and created) over and over in these environments: - Trying to access UI framework elements from the wrong thread - not understanding that a callback inside one of the included libraries is not running on the UI thread but from somewhere else - callbacks capturing references to objects which already had been destroyed (but the callback had been queued and can't be cancelled), and accessing those objects later on - deadlocks, due to mutex locking in both callbacks as well as the "normal" code. There are ways to minimize the amount of issues, e.g. always deferring asynchronous callbacks to the next eventloop iteration, making sure that callbacks are queued on the main thread instead of an arbitrary one, deferring object deletion behind all other callbacks, etc. But these are on the harder to learn, teach and enforce side. Therefore I would agree with the author of that article that the mixture of eventloop-based programming and multiple threads is the hardest combination.