Almost agree but not quite. From my experience it is _often_ a worse approach and using built-in concurrency units (Erlang actors, goroutines, even threads with queues).
Small demos or applications with very short callback chains benefit and look good with this type of concurrency.
You are right this is nothing new. HAproxy and nginx are very fast, very heavily used applications, they use an async event loop (select/epoll) type reactor. But that is a good fit for them because, their callback chains are very short and they don't do that much CPU heavy processing.
But as applications get larger and these callback chains start forking into errback and get deeper and deeper this is not a good paradigm for design.
Comments
Almost agree but not quite. From my experience it is _often_ a worse approach and using built-in concurrency units (Erlang actors, goroutines, even threads with queues).
Small demos or applications with very short callback chains benefit and look good with this type of concurrency.
You are right this is nothing new. HAproxy and nginx are very fast, very heavily used applications, they use an async event loop (select/epoll) type reactor. But that is a good fit for them because, their callback chains are very short and they don't do that much CPU heavy processing.
But as applications get larger and these callback chains start forking into errback and get deeper and deeper this is not a good paradigm for design.
Anyway just my two cents.