Cool, but why? The traditional arguments in doing something like this would be to access the libraries available on something like .NET. However, the point of building Node on V8 is to avoid existing, non-async libraries.
It is interesting to me, at least, for the same reasons that made Node.js interesting in the first place: as a statement/experiment in seeing how far the async model can be pushed.
I'm a .NET dev by trade but became immediately interested in Node.js for that very reason.
In the .NET case, a Node-like project is in an interesting position: lots of long-running/externally-bound third-party (and even a few first-party) APIs are blocking in nature, except that if they were following the design guidelines they would all provide non-blocking alternatives based on a set of implementation patterns provided by and followed in the .NET base class library itself. Those implementation patterns would be relatively easy to generically wrap into the kind of callback pattern used by Node.js.
At the very least, a project like this has a possibility of highlighting some of the places where only blocking APIs have been provided but non-blocking ones should have also been provided. On a slightly more optimistic note, a project like this has a chance of allowing more solutions to be built in the Node.js events-instead-of-threads style without having to jump ship to an entirely different runtime.
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.
Well, for one thing, AFAIK Node right now doesn't work on Windows. This effectively brings (albeit a limited) Node.JS to Windows users.
And also, considering how HN is crazy about experimental languages, compilers, frameworks and combinations of them, I'm surprised with this question. The title of the post actually reminded me to the output of a certain HN title generator that was here a while ago.
Which is like saying "why not just use V8?" when talking about Node.js. IronJS, once it is ready, will likely be the best JS implementation (and its certainly the one I have my sights on!) through which to build and run a Node-like JS server on .NET but you'll still need to build the Node-like implementation itself (hopefully mostly if not entirely in JS.)
I realize that running Node on top of the .net runtime will probably be significantly slower than running it on top of the highly optimized V8 engine, but some perf numbers would be interesting nevertheless.
I don't think a javascript engine will ever be faster than .NET. Not debating the quality of the runtime, but win32 I/O Completion Ports and WSAAsyncSelect are up to par with Unix's (e|k)poll. With win32, your data will be hitting processor registers before the javascript engine ever has a chance to typecheck its arguments.
Never underestimate the sheer power of easily circumventable abstractions ;-)
