How many of those libraries are thread-safe? A blocking-but-threadable (with arbitrary number of threads) API can be relatively trivially converted to an event-based one, at the cost of a thread and some relatively-automatable coding grunt work.
Honest question. I have no visibility into the .Net ecosystem and have no idea if threading is exceptional or normal.
Within the Framework's Base Class Libraries themselves, the documentation is pretty good about stating what is and is not thread-safe and the implementations are generally quite good in that regard. Outside of the Base Class Libraries there is a lot of variability in thread safety, of course, so YMMV depending on what you're working with.
That said, the thread safety isn't as critical in something like Node, at least not in the sense you'd usually be worried about, as the execution model is explicitly single-threaded. What you'd be more interested in finding (and pushing to improve) would be libraries that are externally bound but fail to provide an async option using the recommended async patterns for .NET. To be clear, these recommended async patterns and a good number of their proper implementations do not require hidden threads for their async behaviour, as when built correctly they are layered upon lower-level async operations that themselves do not require threads.
One would hope to work towards a "turtles all the way down" kind of scenario where eventually nothing you are using blocks on anything external and instead uses the async primitives and layers them up such that no threads are needed for any async operations. Admittedly, as .NET goes there would be areas you can't achieve that goal, however, as some framework bits are secretly backed by threads (e.g. some serial port handling, when last I checked), but this is also true in the case of Node.js which itself maintains threads behind the scenes for use with otherwise-unavoidable blocking code. In either Node-style case the end goal is the same: to minimize if not eliminate the need for such threads, and in the .NET-specific case it should be largely achievable (to the degree that it matters) as there are plenty of building blocks with proper async options.
Much of the efficiency gains of non-threaded event-based systems like node.js come from not having "the cost of a thread," so creating threads to work around blocking apis would eliminate a large part of the point of having such systems in the first place. You still get the advantage of not having to deal with the other issues inherent in threading, but you lose the low memory and cpu usage.
I'll admit that I don't know much about Node.js beyond the (very) basics, but if this (not having "the cost of a thread") is where Node.js shines, then this project might be very good on top of the .NET CLR 4.0. There's been a lot done under the hood to support async / parallel processing (specifically, reworking and optimizing the built-in ThreadPool, which is used for very short tasks to avoid "the cost of a thread").
Yes yes yes, but being able to do something like shrink a PNG every so often with a thread could be the difference between being able to use Node.js.net and not. And later you can slide in a async solution later if one develops.
Honest question. I have no visibility into the .Net ecosystem and have no idea if threading is exceptional or normal.