Can someone provide some different use cases which can be implemented in Rust and Node.js so I can compare their working performance.
My Aim is -
I want to check that which one is fast Node or Rust.
The Million Digit Fibonacci Number Challenge!
Calculate the first number in the Fibonacci sequence that is one million digits long, fibo(4784969).
On my PC at the time took 12 seconds to calculate in Javascript/Node, only 20ms to 300ms in Rust depending on the big integer library used.
All code for calculating for fibo(4784969) in JS, Rust and many other languages here: GitHub - ZiCog/fibo_4784969: The million digit Fibonacci number challenge. Calculate fibo(4784969) in various languages.
6 Likes
Disregarding bare numbers, here some structural differences that come to my mind:
Node.js is (sort of) interpreted (even though there are interpreters with very sophisticated optimizations such as just-in-time compilation, I guess), while Rust gets compiled in a classic way.
Node.js requires a bigger runtime environment than Rust. While (sync) Rust has a very minimal runtime environment, async Rust requires some executor. Nonetheless, comparing that with Node.js/ECMAScript, you'll need garbage collection when executing such script code. Rust doesn't need garbage collection, and even reference counting isn't needed in every situation.
I think the way Node.js utilizes multithreading is through worker threads. The language itself (ECMAScript/JavaScript) isn't made with multithreading in mind. This is different in case of Rust. Rust's &mut references and aliasing rules make it easy for the compiler to know that there will be no concurrent access to some memory location.
As I'm not really an expert for JavaScript, feel free to correct me if I said something wrong on that matter.
1 Like
I think you have summed up the situation nicely.
Nodes is based on the V8 JS engine used in Chrome. Perhaps the fastest JS engine there is. V8 will JIT your code into native executable code on the fly.
JS does not understand threads, however it is based on an asynchronous execution model where everything is driven by events, be they mouse clicks or keyboard hits in a browser or network packets and such arriving in a node.js application, which saves JS programmers from having to worry about threads. This was a smart move for the intended application in the browser and turns out to be pretty efficient for handling lots of network activity in node. Much like async in Rust is.
The JS event driven model is great for juggling thousands of network connections and juggling with requests and responses but is not suited to lengthy computational work. When JS hangs up doing a long calculation all those other events arriving have to wait.
The upshot of all this is that when doing a lot of communications, waiting on requests, DB responses, etc and little computation I suspect to see little speed gains from using Rust instead of JS.
However, we switched from node.js to Rust three years ago. Mostly for reasons not related to performance or any technical merits, but that is another story... I am very happy we did because of the confidence I can have in the Rust code we have created. The strong typing and anti-aliasing rules of Rust make it so much easier to create robust, correct, reliable code. The speed gains are a bonus.
By the way, my fibo challenge above is only a bit of fun. The result of a long forums discussion years ago. Probably a fine example of something one should not really be doing in an interpreted language.
5 Likes
Both are fast.
1 Like
Ha! Quite so.
Our OP asked for "working performance". Which as usual depends on what work one is wanting to do. Perhaps the speed gains of switching to Rust hardly make any difference to the overall task.
1 Like
In general:
-
If the app is largely waiting for I/O, e.g. it spends a lot of time reading or writing files, or communicates over the network, then it doesn't matter that much what language you write it in, because it spends most of the time waiting anyway.
-
Certain compute-heavy tasks can be fast in Python, R, etc because the heavy lifting is delegated to embedded code written in C, C++, Rust etc.
-
In all other cases, natively compiled languages like C, C++, Rust, etc decisively beat interpreted languages.
-
A number of languages, including Python, JavaScript, Java, Scala, are compiled to run in a "VM", but that so-called VM is basically an interpreter
-
Some of these interpreters that are called VMs employ just-in-time compilation, which means some of your code is compiled to native code, which is then also fast, but that works well only in limited cases.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.