I would recommend that you take another look at node.js. One of the biggest problems with using libraries to do event-based programming in an object-oriented programming language (rather than using an event-based programming language in the first place), is that usually all the other existing libraries are not event-based and it is really awkward to mix event-based and synchronous I/O. In fact, it is pretty much impossible, or more precisely, it is possible but destroys all the benefits of using event-based I/O in the first place. (Note that pretty much any third-party library you use (and the libraries that they use, and so forth), including the standard and core libraries of the language itself, must event-based, to actually reap the benefits. Otherwise, you'll spend the most time of your project writing asynchronous wrappers around existing libraries.)
Now, if using event-based libraries is such a bad thing, then why do I recommend node.js? Simple: ECMAScript doesn't have any synchronous I/O libraries (because of the simple fact that it doesn't have any I/O libraries at all), so the mixing problem simply doesn't arise. (Actually, it has some I/O libraries, like XmlHttpRequest
or Web Sockets, but guess what: those are already all event-based.)
node.js implements all I/O libraries itself, all event-based, without backwards-compatibility or legacy requirements.
Otherwise, every language or platform has some event-based or asynchronous I/O libraries: Ruby has EventMachine and Rev, .NET has Rx, the JVM has NIO, Unix systems have kqueue/epoll, C has libev and libeio (on top of which node.js and Rev are built), Perl has AnyEvent (built on top of libev by the same author) and so on.