[tptacek]

Real evented code isn't a series of onRead/onWrite callbacks, because real evented code buffers strategically, and abstracts itself into state machines with simple callback interfaces, so that the rest of the program can be written in terms of higher level events.

I don't want to turn this into "events work for every program", because like I said above: I don't think event interfaces work for all kinds of programs. I've found them poorly suited to full-featured web frameworks, for instance.

I did not predict this incredibly boring "evented runtime vs. evented API" controversy, but will dispense with it by saying that it is incredibly boring, so you win it in advance. :|

[cmccabe]

I don't see the "evented runtime vs. evented API" issue as boring. This kind of thing is the core of any application you are going to build; it's hardly a minor or nitpicky issue.

Using non-blocking APIs requires you to turn your application "inside out", putting state that would normally have been on the stack into a state machine. You wind up in a maze of callbacks and low-level details.

This kind of thing might be appropriate for writing high performance code in C, but it's a mystery to me why anyone would want to do it in a higher-level language.

[lmm]

It forces you to keep your methods short with reasonably appropriate boundaries between them. Good programmers should be doing this anyway, but an event/callback API at least prevents you from writing a 300-line "do everything" method.