This isn't the first time Node.js has served as conceptual fodder for a similar platform, written to a different language. I noted awhile ago a project that was formerly called Node.x but now has a new name that I've forgotten. That project is implemented in Java and supports developing asynchronous oriented software in any of the languages that run on the JVM.
I haven't looked at the Node.native - so here's a bit of handwaving prognostication.
By using JavaScript/V8 for Node.js we gained the advantage of a high level language, and most importantly do not have to worry so much about memory leaks. It's still possible to write memory leaks in JavaScript, but much harder. Contrarily C++ is also a high level language, but one that's more complex than C++, and most importantly C++ programmers have a tough time dealing with memory leaks.
Daniel Kang, the founder of the Node.native project, is doing this for performance reasons. That's another of the tradeoffs, because V8 imposes a performance overhead. To some it doesn't matter how blisteringly fast you believe V8 to be, some will always think that any interpreted or dynamically compiled programming platform is slower than a natively compiled platform like C++. Further, there are applications such as encoding video streams where JavaScript isn't appropriate. Obviously this is a matter of using the right tool for the job. The typical web application could well be fast enough when written in JavaScript and Node.js while a video transcoding server should be written in C++.
That is - the JavaScript language offers many programming advantages but it isn't the be-all-end-all of programming languages.
Another way to crack this nut is to work on facilitating integration of native libraries. Here's another tradeoff with Node.js, in that there's a slew of native coded libraries available for all kinds of things, but to use those libraries in Node.js requires building a wrapper library to make its commands available as functions in a Node module. Clearly with Node.native you don't have this consideration, instead you just link the library into the process, unless the library doesn't cooperate very well with asynchronous programming.
#include <iostream>
#include <native native.h="">
using namespace native::http;
int main() {
http server;
if(!server.listen("0.0.0.0", 8080, [](request& req, response& res) {
res.set_status(200);
res.set_header("Content-Type", "text/plain");
res.end("C++ FTW\n");
})) return 1; // Failed to run server.
std::cout << "Server running at http://0.0.0.0:8080/" << std::endl;
return native::run();
}
</native></iostream>
http://www.theregister.co.uk/2012/02/17/node_js_native_c_plus_plus/