

Node.net - Node.js implemented in Javascript on the .NET runtime - pufuwozu
http://github.com/dnewcome/Node.net

======
jherdman
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.

~~~
tpz
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.

~~~
jerf
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.

~~~
necubi
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.

~~~
profquail
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").

------
pufuwozu
Blog post from the creator:

[http://newcome.wordpress.com/2010/05/08/node-net-node-js-
imp...](http://newcome.wordpress.com/2010/05/08/node-net-node-js-implemented-
in-javascript-on-the-net-runtime/)

------
darrenkopp
Why not just use IronJS? <http://ugh.cc/>

~~~
tpz
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.)

------
niktech
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.

~~~
mahmud
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 ;-)

