Wow! The integration with rayon for data parallelism is especially interesting, and I imagine that could be a killer feature for some people looking to accelerate compute-heavy node.js code without having to deal with the nastiness of parallelism in C++, or C++ at all.

I can see this being useful in combination with Piston[1] to achieve scripting for game engines, in the same way Lua is normally used. Rust as a core for a game engine seems like a really great idea, considering the speed and safety benefits it provides.

Did Yehuda ever open source or complete a similar abstraction like this but for Ruby? I remember someone mentioning to me he was working on it. I have a longstanding todo (though I have no motivation because I currently have no use for Rust or Ruby) to try something similar though I remember my initial attempts having trouble with how Ruby's C API expresses some values.

There's an API thing from the JS side I don't understand, and I didn't find anything documentation-wise (maybe it's just because I haven't had my coffee yet):

require('neon-bridge').load()

So this loads... which rs file, exactly? Where do I specify the Rust file to be loaded? Or is there just a single entry point and you're supposed to have one singular Rust module that is named by convention?

Rust is a compiled language, so the JS files don't directly load a .rs file but instead they load a native Node extension, i.e. a .node file, which is generated by compiling and linking the Rust sources. (The node-cli tooling automates the whole build process.)

The line you cited is automatically locating the .node file, loading it, and returning the module object associated with it.

On IRC a couple people have been questioning this part of the API, suggesting that just using the standard npm module `bindings` might be better. It's a reasonable idea and I'll probably open a discussion in a GitHub issue.

I realize that Rust is a compiled language, that's not the issue. The syntax somehow suggested to me the modules could be compiled on demand, but that is not the issue either.

My question is/was, given two or more modules written in Rust, how do I address and require them by name? Due to its naming I assumed "neon-bridge" would be the glue that handles this. Given the fact that you can require .node files directly, it was not clear to me that "neon-bridge" is just the name of an example module (or is it?).

So neon-bridge is a utility npm package I published that automates loading your Neon project (so it's not the name of an example module). And the expectation is that you only have one Rust package ("crate" in Rust parlance) per Node package, which is why you don't need to pass it the name of anything -- it's looking for _the_ native module in the package, as opposed to _a_ native module.

However, that single Rust crate may have multiple modules in its implementation. They live in the src/ directory of your Neon project and are picked up by the Rust compiler and build tool.

The reason that I'm using Rust and Node together is Lambda. It supports Java, Python and Node and my (admittedly perfunctory) tests showed that Node had the smallest overhead of the three in getting to Rust. However, this library seems to offer a richer interaction between the two platforms, which would imply using Node as something beyond a bridge to Rust, so there's likely an answer beyond mine that the author has in mind.

This is fantastic! Great idea and job so far! One of the biggest disadvantages with node is any type of complex manipulations / processing due to the single threaded, scheduler paradigm but combining node with native modules makes it much easier to pass off more complex pieces directly to C++.

Passing off to rust? Count me in! I'll be taking a look at this when linux is supported (would also love windows support but mac os x and linux are necessary for me).

Damn people work fast. I hadn't even looked into what it would take to support Linux (and honestly my rust knowledge at the moment is so limited I probably wouldn't have figured it out in a reasonable time frame).

If the goal is having a fast "business-rules engine" coupled to a pretty HTML5-based app-wrapper, one of my own projects is to combine Electron with the Erlang VM.

Rather than trying to go whole-hog on linking the two worlds together at a process level, I've just embedded an Erlang release into the Electron package, which decompresses itself to the user's Library/APPDATA dir on Electron startup, transparently registers as a service (so it can continue to run for things like server sync when the app is quit), and then communicates with the app using Unix domain sockets.

It's a bit like the feeling of having a Service Worker, but one that just happens to be able to embed things like physics engines inside of it.

Ah, I ran into that problem (I think?) and had been just using regular IP sockets as a stop-gap, planning to switch back over after it was fixed. I'm glad to hear someone with knowledge of Electron internals ran into it as well; I feel bad that I didn't file it as a bug, though.

Neon is for creating native Node modules in rust, which are libraries that use the Node addon API [1].

node-ffi seems to be for adding a bridge between an existing non-Node module dynamic library and node, which at the very least seems to incur some non-negligible overhead; see the "Call Overhead" section of your link.

Agreed! In fact it would also be useful in Node: you could build an almost-full-performance but portable version of a native module as a fallback for clients who don't have the requisite software to build a Neon library (say, one they only indirectly depend on) on their machine.