Comment by tpz | Hacker News Reader

Comment by tpz | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com