Node.native - Node.js in C++0x
github.com
github.com
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/
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).
Oh and does anyone know a Perl one?
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?
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.
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.
That still doesn't mean it's a good idea to write a full web app in a C++ event loop while doing your own memory management. I've tried this (in C++11 no less), and it took nearly 30K LOC for me to admit defeat. I wish I were joking.
I'm not a fan of moving away from Makefiles, however. Makefiles are sooo simple, why complicate it?
No. Its not. I've been programming primarily in C++ for a few years (been using it as a hobbyist programmer since about 2002 and on and off professionally over the last 4 years) and this has never been an issue for me.
If you are already writing an application in C++ which needs a web component, this may be an interesting choice.
That's about it.
Please help. (Sorry, noob here.)
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.
But Node.js runs only in a single native thread, right? So it's single threaded I/O multiplexing using epoll/kqueue and the thread calls JS callbacks when some I/O takes place. In C or C++ you could run n native threads serving m sockets using a single "reactor".
You could certainly do what you describe and it would be very similar to node's Cluster module, which uses multiple processes. In fact, I believe in the next release they're giving you the option to replace processes with threads under the hood.
More info: https://groups.google.com/forum/?fromgroups#!topic/nodejs/zL...
Unless the dispatcher is extraordinary slow, the major performance issues are going to be in the userland code more than the actual Node code.
It also makes use of libuv and http-parser, which are used in Node, to offer some of the same out-of-the-box functionality.
edit: it appears that I'm confused as to what this does exactly, my bad. Egg, all over my face.
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.
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.
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.
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".
See pkg/runtime/proc.c (entersyscall, ready, and matchmg).