2 ms·

It's nice to see a demonstration of how to do this by hand! But at work, we use Neon https://github.com/neon-bindings/neon https://github.com/neon-bindings/neon

by ekidd 9y ago

It's nice to see a demonstration of how to do this by hand! But at work, we use Neon https://github.com/neon-bindings/neon https://github.com/neon-bindings/neon to write production Node.js modules in Rust.

kibwen 9y ago
I appreciate the OP's desire to learn how Node's FFI works, but for production purposes utilizing an existing project like Neon is almost certainly the right answer. Interfacing interpreters with native code can be hairy and no two interpreters are alike, so going it alone is going to take a lot of time understanding the nuances and pitfalls of each individual system. Neon is still young yet, but it's from Dave Herman, the head of Mozilla Research, so I'm hopeful that it has a bright future ahead of it.
- curun1r 9y ago
  FWIW, ffi is just a third-party node module, which makes it pretty similar to Neon. Both are solutions that require you to write a bit of glue code and both have their caveats/pitfalls/landmines. Which one is the "right answer" is situational and neither is universally correct. For instance, if you needed to call into both Rust and C/C++, ffi might be a cleaner solution since your JavaScript could basically be the same for both. Using ffi can also be more dynamic than Neon, so if you wanted to do something akin to Java's URLClassLoader that downloads and runs native code at runtime, using Neon would make that a bit harder. The main difference between the two is where you write your glue code...with Neon, you write your glue in Rust and with ffi you write in JavaScript. BTW...I'm a big fan of Neon and have even sent in a PR for an issue I found. I've used it to write Google Cloud Functions without having to write a single line of JavaScript and it's been pretty easy to work with. Rust is the perfect language for Cloud Functions/Lambda since those services are billed per CPU time/memory and Rust has very little overhead in those regards. Writing services that use the minimum allowed resources makes using these serverless platforms very price competitive with running your own servers, even when you reach a pretty considerable load. I do find the current direction Neon is headed (using macros to essentially write JavaScript code in Rust) to be not particularly useful (I'd rather my Rust code look like Rust), but the project is already at a point where I can build around it, so I'm not complaining. Anyways, your comment seemed to imply that ffi was part of the Node platform and that it wasn't appropriate for production, and I disagree with both of those. Ffi is just a different approach that's suitable for different situations.

by ekidd 9y ago

kibwen 9y ago

I appreciate the OP's desire to learn how Node's FFI works, but for production purposes utilizing an existing project like Neon is almost certainly the right answer. Interfacing interpreters with native code can be hairy and no two interpreters are alike, so going it alone is going to take a lot of time understanding the nuances and pitfalls of each individual system. Neon is still young yet, but it's from Dave Herman, the head of Mozilla Research, so I'm hopeful that it has a bright future ahead of it.

curun1r 9y ago
FWIW, ffi is just a third-party node module, which makes it pretty similar to Neon. Both are solutions that require you to write a bit of glue code and both have their caveats/pitfalls/landmines. Which one is the "right answer" is situational and neither is universally correct. For instance, if you needed to call into both Rust and C/C++, ffi might be a cleaner solution since your JavaScript could basically be the same for both. Using ffi can also be more dynamic than Neon, so if you wanted to do something akin to Java's URLClassLoader that downloads and runs native code at runtime, using Neon would make that a bit harder. The main difference between the two is where you write your glue code...with Neon, you write your glue in Rust and with ffi you write in JavaScript. BTW...I'm a big fan of Neon and have even sent in a PR for an issue I found. I've used it to write Google Cloud Functions without having to write a single line of JavaScript and it's been pretty easy to work with. Rust is the perfect language for Cloud Functions/Lambda since those services are billed per CPU time/memory and Rust has very little overhead in those regards. Writing services that use the minimum allowed resources makes using these serverless platforms very price competitive with running your own servers, even when you reach a pretty considerable load. I do find the current direction Neon is headed (using macros to essentially write JavaScript code in Rust) to be not particularly useful (I'd rather my Rust code look like Rust), but the project is already at a point where I can build around it, so I'm not complaining. Anyways, your comment seemed to imply that ffi was part of the Node platform and that it wasn't appropriate for production, and I disagree with both of those. Ffi is just a different approach that's suitable for different situations.