

Node.native - Node.js in C++0x - johnx123-up
https://github.com/d5/node.native

======
johnx123-up
Other projects around libuv:

1\. Mozilla's Rust <http://www.rust-lang.org/>

2\. Tim Caswell's LuaNode <https://github.com/ignacio/LuaNode>

3\. Ben Noordhuis and Bert Belder’s Phode async PHP project
<https://github.com/bnoordhuis/phode>

4\. Kerry Snyder’s libuv-csharp <https://github.com/kersny/libuv-csharp>

5\. Andrea Lattuada's web server <https://gist.github.com/1195428>

6\. Steve Yen's Lua wrapper <https://github.com/steveyen/uv>

Source <http://blog.nodejs.org/2011/09/23/libuv-status-report/>

~~~
yesbabyyes
Nice list, though that's not Tim Caswell's project; this is:
<https://github.com/luvit/luvit>

~~~
tete
Using Moonscript (Lua's CoffeeScript) the performance benefit of LuaJIT when
compared to all JavaScript implementations makes it a really interesting.

Well, actually Lua doesn't look bad, even though it really needs syntactic
sugar for OO, but there is enough of it. Not just Moonscript, but also Loose
(Perl's Moose ported to Lua).

------
exDM69
This is quite similar to boost.asio library, which has got sockets and timers.
I know for a fact that boost.asio is thread safe and you can use several
threads running the same I/O service allowing you to multiplex n sockets to m
threads. Do you guys know whether libuv (and node.native) are thread safe or
not?

~~~
shaka881
No kidding, asio is fast and battle-tested. I only see risks associated with
being an early adopter this. The Node hype is a deafening roar.

------
ramanujan
This is a little off topic, but thought I'd ask the C++11 aficionados who're
viewing this thread. For those who've taken the hit and really explored C++11:

1) What are the best resources to learn how to code C++11 in a Pythonic style?
Looking for a book or production source code example that uses the new
language features idiomatically: lambdas, vector and dictionary literals, and
the like.

2) What does your toolchain look like for C++11? Just the latest gcc and
latest emacs, plus maybe a few tools like makeheaders[1] and gtags[2], or
something more?

[1] <http://www.hwaci.com/sw/mkhdr/>

[2] <http://www.gnu.org/software/global/>

~~~
exDM69
1) What are the best resources to learn how to code C++11 in a Pythonic style?
Looking for a book or production source code example that uses the new
language features idiomatically: lambdas, vector and dictionary literals, and
the like.

I don't think you can find good books or comprehensive resources at this time.
There are various articles and blog posts detailing the C++11 additions to the
language. Of course there's the spec but it makes very boring reading.

Not a whole lot has changed so you can pretty much jump right in and use the
new features as you need them.

std::thread and std::chrono are pretty sweet.

2) What does your toolchain look like for C++11? Just the latest gcc and
latest emacs, plus maybe a few tools like makeheaders[1] and gtags[2], or
something more?

I used to build gcc from git sources, but these days my operating system
package manager ships with a gcc version that has most of the C++11 stuff I
use. Just add -std=gnu++0x to your CFLAGS.

FWIW: I use vim + ctags + cscope.

------
Animus7
A cool hack, but I can't help this feeling pointless in practice.

It solves the problem of using Node userland code to do heavy computation. But

a) serious developers know better than to do heavy computation inside of Node
anyway, and

b) it comes at an enormous, almost unforgivable cost: working with C++ is a
nightmare compared to working with Node when it comes to realtime web projects
(I've been in those trenches)

What would be exponentially more useful in practice is a concise, well-
documented way to hook (multithreaded) C++ code into Node's engine.

But that wouldn't be nearly as sexy as a promise of _Node, but with native
performance_.

~~~
_stephan
Without commenting on Node.native, I'd just like to note that C++11 isn't your
grandparents' C++ anymore. An experienced programmer probably can write code
in C++11 that is almost as elegant as, say, the equivalent C# code. And for
larger projects many people would prefer something like C# to JavaScript, if
only for the static typing.

~~~
baq
the problem isn't writing code, the problem is build environment and
deployment - correct versions of compilers, headers, libraries, makefiles,
cmakelists, wafs, scons', bjams, whatevers...

~~~
alexchamberlain
Is it really an issue? Are you proud of the fact that you can't sudo apt-get a
few packages?

I'm not a fan of moving away from Makefiles, however. Makefiles are sooo
simple, why complicate it?

~~~
pjmlp
Makefiles are only simple if you are only supporting a single operating
system, and a few build configurations.

~~~
dpiers
I've worked on a makefile that built shaders, libs, and assorted executables
for multiple projects across 6 platforms, and I can confirm this.

------
gritzko
What is the dramatic advantage of Node.native over using libev/libevent
directly?

~~~
Animus7
Familiar interface, good pre-packaged core libraries.

That's about it.

~~~
leon_
familiar interface for whom?

------
paramaggarwal
I would like to understand the implications. Does this improve performance? Or
does it just allow coding in C++.

Please help. (Sorry, noob here.)

~~~
exDM69
> I would like to understand the implications. Does this improve performance?
> Or does it just allow coding in C++.

This is practically a C++ wrapper for libuv, the backend of node.js. It allows
you to write code similar to node.js in C++ without using JavaScript and the
V8 JavaScript environment. Does it improve performance? In theory, yes. In
practice, maybe.

The biggest potential win here is that you could run many threads that can run
I/O in parallel. In Node.js/V8 you only have one native OS thread while in C++
you can put many native threads to serve the I/O sockets. It's quite a lot
cheaper to change from one thread to another than it is to change from one
process to another (if you have many node.js processes running) so there is
potential for performance increases if you have some CPU-heavy stuff in your
code. Or you have more sockets/requests to serve than a single CPU is capable
of.

This is assuming that libuv and node.native don't have anything that would
inhibit running in multiple threads. The system calls running underneath
(read, write, epoll/kqueue) are thread safe, but libuv/node.native may have
something that isn't. I didn't double-check.

~~~
johnx123-up
(I submitted the link, but...) Do you think a C port will improve performance
over C++? Google only returns wishlist something like this
<http://rajeshanbiah.blogspot.in/2012/01/nodec-la-nodejs.html>

~~~
alexchamberlain
A properly coded C++ app should run as fast as C; it can be faster...

~~~
lmm
Not while C++ doesn't have restrict pointers

~~~
alexchamberlain
Yeah, all performance benefits of C come from a single under used feature.
</sarcasm>

------
simfoo
Great to see libuv being used in the wild (outside of Node.js). It's a nice
little library that does one thing and does it good.

~~~
noj
FWIW it's also used in the Rust runtime
(<https://github.com/mozilla/rust/tree/master/src>)

------
lperrin
It might be useful to use node-like patterns in platforms where node is not
available (iOS comes to mind).

------
ronreiter
Wow, great work. Really good for both CPU and IO critical missions (a.k.a
people who are cheap on servers)

------
drivebyacct2
I'd kill to have this in Go instead. Looks like it's a wrapper around libuv,
shouldn't be hard with cgo. Hm, maybe another thing to add to the list.

edit: it appears that I'm confused as to what this does exactly, my bad. Egg,
all over my face.

~~~
exDM69
Doesn't Go have it's own asynchronous I/O system built into the language
runtime? I was under the impression that Go has I/O multiplexing w/green
threads similar to Haskell. So when you write socket.read(), it will be put
into an epoll/kqueue behind the scenes and a co-operative green thread switch
occurs. This way you don't have to write dirty I/O callbacks like in Node.js
or Boost.Asio but you get the same effect with neater code.

So if Go has this feature, using libuv would not only be useless, it would be
harmful because it doesn't play nice with the language runtime w.r.t.
parallelism.

I think that writing asynchronous parallel code should be done by the compiler
and the runtime, not by the coder. Node.js code is a mess of callbacks that
have to be written in continuation passing style by the user. Haskell (or Go?)
code that has the same effect is written like regular imperative code, which
is transformed into Node-style callback code by the compiler and multiplexed
by the runtime. Compilers are excellent in doing this kind of transformations.

~~~
jbarham
Almost, but not quite.

From <http://golang.org/doc/effective_go.html#goroutines>: "Goroutines are
multiplexed onto multiple OS threads so if one should block, such as while
waiting for I/O, others continue to run."

So the Go runtime doesn't automagically transform blocking system calls into
non-blocking calls, but if one goroutine is waiting for I/O, other goroutines
can run in the meantime.

But you're right in that with Go you can write simple, easy to debug
imperative code, but at the same time confidently spawn 10's of thousands of
goroutines because they're so lightweight compared to conventional OS threads.
The Go runtime handles the bookkeeping of multiplexing goroutines over real OS
threads.

~~~
exDM69
> So the Go runtime doesn't automagically transform blocking system calls into
> non-blocking calls, but if one goroutine is waiting for I/O, other
> goroutines can run in the meantime.

But when using Go's standard file.read or socket.write, what you get is I/O
multiplexing of goroutines (with epoll or kqueue) in the runtime.

Naturally, if you call a C library from Go that uses unix read or write and
executes a blocking system call, that cannot be magically intercepted by the
Go runtime.

~~~
zemo
...what? All file.Read does is wrap the read syscall. There's no concurrency
in file.Read.

~~~
exDM69
It seems like goroutines in Go don't do as much asynchronous stuff as
Haskell's I/O manager and green threads do. Looking at Go sources, there is
some async stuff w/epoll in the net library with sockets, but file.Read is
indeed just a plain syscall.

It makes me wonder, what happens to a goroutine when a system call blocks. Go
is supposed to mux many goroutines to a smaller number of OS threads, but what
happens when one of those threads has been blocked in a system call?

There are plenty of vague descriptions on how goroutines work but none of the
ones I found quickly explained what happens on a blocking system call that
allows another goroutine to run, apart from hand-waving about "another
goroutine running".

~~~
trevorstrohman
The Go runtime keeps track of the number of goroutines that are currently
executing and ensures that this doesn't go above GOMAXPROCS. As soon as a
goroutine enters a system call it is excluded from this count. If there aren't
enough threads to run GOMAXPROCS goroutines the runtime may launch a new one.

See pkg/runtime/proc.c (entersyscall, ready, and matchmg).

