There are a few basic use cases I envision being the most common:
- When you have a portion of your Node app you really want to optimize (Rust's baseline computational performance is generally much faster than Node's and is easier to optimize predictably).
- When you have a part of your algorithm that you want to parallelize.
- When you want access to native libraries and need some glue code to expose it to JS.
One important caveat: there's a significant cost to calling back and forth between Node and Rust (I hope I can improve the cost over time but it'll never be free), so the use cases that fit the best will be ones where you're doing a lot of work in Rust so the amortized cost of crossing that boundary is small compared to the savings you get from Rust.
8 comments
[ 2.6 ms ] story [ 29.3 ms ] threadLike, which sub set of modules are better as a native version and which sub set of these are better written in Rust?
https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h...
Edit: you could also do safer C/C++ interop with JS through Rust, if you want to use some legacy code.
- When you have a portion of your Node app you really want to optimize (Rust's baseline computational performance is generally much faster than Node's and is easier to optimize predictably). - When you have a part of your algorithm that you want to parallelize. - When you want access to native libraries and need some glue code to expose it to JS.
One important caveat: there's a significant cost to calling back and forth between Node and Rust (I hope I can improve the cost over time but it'll never be free), so the use cases that fit the best will be ones where you're doing a lot of work in Rust so the amortized cost of crossing that boundary is small compared to the savings you get from Rust.