[DanWaterworth]

Hi, I work at a company that makes heavy use of event loops. I'll try to accurately convey what I know:

From an efficiency standpoint, using event loops requires much less memory, but marginally more CPU time than threaded approaches.

In terms of maintenance, you're essentially writing your programs in continuation passing style which means error handling is explicit everywhere. There are tools that allow you to hide this like streamlinejs, Haskell's continuation monad transformer and to a lesser degree, promises/futures/deferrables. If you decide to stick with callback passing, then a good knowledge of functional programming is useful as all loops require recursion. If your application is single threaded, that tends to make finding race conditions easier, but on the whole I'd say it's harder to write good asynchronous code than it is to write good synchronous code.

[willbmoss]

At high concurrency, I'd argue you will probably end up being more cpu efficient as well. The cost of context switching effectively larger frames and getting into and out of privileged mode can get expensive.

[CookWithMe]

I don't know what exactly you are referring to with high concurrency, but if you mean "high number of tasks to work on in parallel" then a ThreadPool will eliminate the problems you are describing.

[DanWaterworth]

It probably depends, but the cost of creating a heap allocated closure and then running it and deallocating it can be quite high against the cost of 2 context switches.