It's a pretty exciting time for Neon. We're nearly feature-complete for a 1.0 release, which will come with a bunch of benefits and should help us build momentum for future improvements:
* No more legacy backend -- just one simple and clean way to use Neon, fully audited for safety.
* Strong ABI and API stability guarantees.
* Convenient APIs for general-purpose multithreading and creating custom async Node events.
* Ergonomic and modern use of JS promises, which interact beautifully with async Rust code.
js_rust_library(... defs = ["someFunction"] ...)
If you're interested in playing with any of these ideas feel free to hop onto our community Slack and chat!
I've considered it. But honestly, I don't know a lot about WASM (I should explore it more), so I haven't compiled it to WASM. Maybe some members of the community can provide more insights.
It is definitely something I'll try to check at some point later.
One difference is that NAPI-RS uses Node’s N-API for calling Node, and Neon has a mix of N-API and v8 backends. I’m not sure if this is the main reason behind the speed difference or not.
Because there's rarely a real benefit to this approach.
I have yet to found use case where C/C++/Rust library is useful AND spawning process to do heavy work is not a viable option AND JS-only library won't work.
I can think basically only about communication with external resource like database.
And when it is a database, all the benefits of a compiled language turn into just a fancy no-brainer wrapper which still sucks because of “impedance mismatch”. It would be nice if that was true jit-integrated rust or at least C ffi, which one could call directly from js. But I don’t think that v8 will get such capability in observable future.
What happens when the user in JS land passes in an incorrect data type? Does it segfault? Does it truncate the first 32 bits?
JsNumber::value() then returns an f64 to encapsulate all possible JS numbers, and `as i32` is just casting that float into an int. The exact behavior for this cast is that a) any fractional component will be dropped, and b) if the number is larger than the destination type, the destination's maximum value will be used. Both of these behaviors could of course be controlled by adding logic, like an explicit call to .round()
Obviously, you should handle such cases properly.