# NodeJS vs Rust
**URL:** https://forum.duniter.org/t/nodejs-vs-rust/4782
**Category:** Dunitrust
**Created:** [7 June 2018 11:54 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782 "2018-06-07T11:54:04Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [7 June 2018 11:54 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/1 "2018-06-07T11:54:04Z")
> [@État d'avancement de Durs (Dividende Universel Rust)](https://forum.duniter.org/t/etat-davancement-de-durs-dividende-universel-rust/4777/4):
>
> Attention : si tes motivations sont de montrer que tu peux faire mieux que ce que j’ai fait, c’est un chemin qui ne mènera pas bien loin.
Arf non au contraire. J’ai souhaité préciser que si la sync est bien plus rapide avec durs c’est parce que rust est plus performant que nodejs, si je ne l’avais pas précisé on pourrait penser que j’ai mieux coder la sync que toi, ce dont je doute fort 😅
La compétition c’est pas mon truc 😉
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [7 June 2018 12:09 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/2 "2018-06-07T12:09:21Z")
> [@État d'avancement de Durs (Dividende Universel Rust)](https://forum.duniter.org/t/etat-davancement-de-durs-dividende-universel-rust/4777/8):
>
> J’ai souhaité préciser que si la sync est bien plus rapide avec durs c’est parce que rust est plus performant que nodejs
Oui mais je ne suis pas sûr que ce soit pour ça, l’algorithme utilisé joue un rôle majeur. Selon les opérations que je fais sur la synchro, je peux effectivement descendre à quelques secondes.
Par exemple il semble que tu stockes les DU dans un fichier à part, c’est peut-être justement là que tu gagnes beaucoup en performances (et ce serait bien vu ! je vais tester cela aussi).
> [@État d'avancement de Durs (Dividende Universel Rust)](https://forum.duniter.org/t/etat-davancement-de-durs-dividende-universel-rust/4777/8):
>
> si je ne l’avais pas précisé on pourrait penser que j’ai mieux coder la sync que toi, ce dont je doute fort 😅
Bof, l’algorithmie n’est pas le code, tu peux très bien avoir choisi un algo plus efficace. Et ce serait tant mieux, car je pourrais aussi en faire profiter DuniterTS.
> [@État d'avancement de Durs (Dividende Universel Rust)](https://forum.duniter.org/t/etat-davancement-de-durs-dividende-universel-rust/4777/8):
>
> La compétition c’est pas mon truc 😉
Moi non plus ! Sauf quand c’est bon enfant, là j’aime beaucoup 🙂
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [7 June 2018 12:12 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/3 "2018-06-07T12:12:42Z")
> [@État d'avancement de Durs (Dividende Universel Rust)](https://forum.duniter.org/t/etat-davancement-de-durs-dividende-universel-rust/4777/10):
>
> Oui mais je ne suis pas sûr que ce soit pour ça, l’algorithme utilisé joue un rôle majeur. Selon les opérations que je fais sur la synchro, je peux effectivement descendre à quelques secondes.
Je n’ai pas parallélisé au maximum, actuellement la sync prend 5,9 secondes sur mon pc, si je me fait chier a parallélisé au max je peut descendre en dessous de 3 secondes. mais je ne me ferai pas chier a le faire car de toute façon la phase de download prendra plus que 6 secondes don ce serait un gain inutile.
Ce que je veut dire c’est qu’a algo équivalent rust est forcément plus rapide que node.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [7 June 2018 12:40 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/4 "2018-06-07T12:40:59Z")
> [@elois](#):
>
> Ce que je veut dire c’est qu’a algo équivalent rust est forcément plus rapide que node.
C’est certainement vrai, quoique, mais en l’occurrence je pense que les algos sont très différents et donc que la comparaison n’était pas justifiée. J’ai vu ta remarque un peu comme du Node bashing, ce qui n’est justement pas un esprit bon enfant.
> [@État d'avancement de Durs (Dividende Universel Rust)](https://forum.duniter.org/t/etat-davancement-de-durs-dividende-universel-rust/4777/5):
>
> NodeJS / TypeScript pouvant être perçu comme préférable pour du front
Ce qui est est perception fausse, mais pour comprendre ce point il faut étudier NodeJS et comprendre là où il est plus efficace que du C++ ou du Rust.
Les gars qui ont produit NodeJS ne l’ont pas fait pour JavaScript, il se trouve qu’ils ont prit ce langage mais c’est un peu un hasard et le fondement de ce projet est ailleurs.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [7 June 2018 12:43 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/5 "2018-06-07T12:43:03Z")
Note : j’ai déplacé ces posts sur un autre sujet pour éviter de polluer le sujet initial.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [7 June 2018 12:48 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/6 "2018-06-07T12:48:56Z")
> [@cgeek](#):
>
> J’ai vu ta remarque un peu comme du Node bashing
Je ne crache sur aucun langage, d’ailleurs j’ai pris plaisir a faire du Nodejs 🙂
Simplement, en vue des connaissances que j’ai de fondements de ses différents langages il me semble que Rust sera toujours plus rapide a algo équivalent car il fait des optimisations poussés jusqu’a niveau assembleur. Et aussi car il n’y a pas de runtime.
Donc aussi optimisée et efficace que soit la VM Node, elle perd forcément un temps à l’interprétation.
Ce qui permet en contre parti un codage plus simple et plus rapide. Comme je l’ai dit aux rml11, Rust a aussi sont lot d’inconvénients (long a coder, dur à apprendre). Il ne s’agit donc pas de confronter Rust et Node pour savoir si l’un serait mieux que l’autre, ils ont chacun leurs avantages et inconvénients.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [7 June 2018 14:01 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/7 "2018-06-07T14:01:03Z")
> [@elois](#):
>
> il me semble que Rust sera toujours plus rapide a algo équivalent
Les gars de Node prétendent que non, précisément car les threads ont eux-mêmes un coût de création (CPU + mémoire).
Sur des applications à forte I/O, typiquement une application réseau, Node permet de tenir une charge plus importante que du Java précisément car le modèle standard en Java pour le web est 1 requête = 1 thread. Et pourtant Java est largement plus rapide que du JS à l’exécution.
Si donc Rust suit la même logique en créant des threads à tout va, il se peut qu’il ne soit pas toujours le plus rapide.
---
### Author:  [@jytou](https://forum.duniter.org/u/jytou)
#### Post date: [7 June 2018 14:09 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/8 "2018-06-07T14:09:02Z")
Je ne connais pas les logiques Rust ou Node, mais un thread, ça se réutilise. Typiquement en java par des Executors plutôt que par du new Thread. 🙂
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [7 June 2018 14:09 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/9 "2018-06-07T14:09:39Z")
> [@cgeek](#):
>
> Sur des applications à forte I/O, typiquement une application réseau, Node permet de tenir une charge plus importante que du Java précisément car le modèle standard en Java pour le web est 1 requête = 1 thread.
Cool, ce serait intéressant de faire des tests comparatifs sur une grosse quantité de requêtes réseau 🙂
Après Java possède un runtime et est beaucoup plus lent que du C++ c’est pourquoi il n’est pas utilisé pour les jeux temps réel par exemple. A voir donc, mais mon intuition me dit que le petit gain qu’obtient Node en ne gérant pas de threads ne compense pas sa perte en vitesse d’exécution face a du Rust.
Ceci étant, seul l’expérience nous permettra de le savoir !
---
### Author:  [@nanocryk](https://forum.duniter.org/u/nanocryk)
#### Post date: [7 June 2018 14:16 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/10 "2018-06-07T14:16:29Z")
> [@cgeek](#):
>
> Si donc Rust suit la même logique en créant des threads à tout va, il se peut qu’il ne soit pas toujours le plus rapide.
Pour la crate wot on à utilisé `rayon`, qui crée autant de threads qu’il y a de coeurs, répartie les taches sur chaqu’un des threads et fonctionne par work-stealing : si je n’ai plus de travail dans ma file d’attente, je vais piquer dans celle de mes voisins. C’est beaucoup plus efficace que la création d’un thread à tout va.
En fait, je ne sais même pas si Rust expose les threads dans sa bibliothèque standard 😛 Je pense que c’est plutôt différentes crates qui proposent différents fonctionnement au dessus des API système.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [7 June 2018 14:31 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/11 "2018-06-07T14:31:49Z")
Voilà, il y a plein de choses possible à faire avec les threads. Go fonctionne encore différemment.
Au final un même algorithme peut être traité différemment selon le meta-algorithme qui le traite, qui lui joue avec les threads et les cœurs de la machine. Et les performances selon les cas d’utilisation pourront être très différentes.
Bref je ne vais pas épiloguer davantage ni même chercher à montrer qu’il est possible de trouver des cas où Rust est plus lent, seulement dire qu’il ne s’agit pas d’une espèce de Graal en termes de performances par le simple fait d’être une application Rust. Ce serait juste faux.
---
### Author:  [@nanocryk](https://forum.duniter.org/u/nanocryk)
#### Post date: [7 June 2018 14:37 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/12 "2018-06-07T14:37:24Z")
D’ailleur le borrowchecker de Rust et l’absence de GC est en même temps un avantage et un désavantage : il permet d’avoir du code safe et sans runtime, mais rend complexe (et demande l’utilisation de code unsafe) la réalisation de certaines structures de données disponibles dans d’autres langages. Chaque langage à ses spécificités, avantages et inconvénients.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [7 June 2018 15:01 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/13 "2018-06-07T15:01:47Z")
> [@cgeek](#):
>
> chercher à montrer qu’il est possible de trouver des cas où Rust est plus lent
Ben j’ai pas mal cherché parce que perso je n’y croyais pas, et a ce jours je n’ai pas encore trouver d’exemple ou Rust est plus lent, c’est… décontenançant 😅
---
### Author:  [@1000i100](https://forum.duniter.org/u/1000i100)
#### Post date: [8 June 2018 23:05 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/14 "2018-06-08T23:05:03Z")
Si rust est top, même converti en webassembly, peut-être qu’un jour il y aura un Gvu en rust pour les script serveur + webassembly+webgl+webcl, le front également généré depuis rust…
Mais très longtemps avant ça, j’aurais écrit un hello-world en rust 😛 (et peutêtre quelques bench rust, go, nodejs, et es6, webassembly, webcl aussi).
Rdv dans 5 ans !
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [8 June 2018 23:16 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/15 "2018-06-08T23:16:39Z")
> [@1000i100](#):
>
> Rdv dans 5 ans !
C’est tellement ça 😃
---
### Author:  [@batisteo](https://forum.duniter.org/u/batisteo)
#### Post date: [9 June 2018 11:17 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/16 "2018-06-09T11:17:47Z")
Après les deux mondes ne sont pas étanches. Si un morceau de l’implémentation en NodeJS bloque, il reste la possibilité d’y injecter un peu de Rust 🙂
> **[Writing fast and safe native Node.js modules with Rust - RisingStack Engineering](https://blog.risingstack.com/node-js-native-modules-with-rust/)**
>
> In this Rust tutorial, I’m going to walk you through the steps of writing a modern, fast and safe native Node.js module.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [9 June 2018 12:15 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/17 "2018-06-09T12:15:33Z")
Oui, d’ailleurs historiquement les parties intenses en utilisation CPU ont été écrites en C++ pour Duniter.
Mais Eloïs a déjà [commencé à migrer le module de WoT en Rust](https://forum.duniter.org/t/du-rust-dans-nodejs-grace-a-neon-le-courant-passe/4611).
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [9 June 2018 22:44 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/18 "2018-06-09T22:44:56Z")
> [@cgeek](#):
>
> Les gars de Node prétendent que non, précisément car les threads ont eux-mêmes un coût de création (CPU + mémoire).
>
> Sur des applications à forte I/O, typiquement une application réseau, Node permet de tenir une charge plus importante que du Java précisément car le modèle standard en Java pour le web est 1 requête = 1 thread.
Il semble que les gars de Node est raison sur ce point, et d’ailleurs des dev de bibliothèques Rust en on tenu compte, pour preuve la description de la crate Rust `ws` que je vais utiliser pour WS2P :
> This library provides an implementation of WebSockets, RFC6455 using MIO. **It allows for handling multiple connections on a single thread, and even spawning new client connections on the same thread.** This makes for very fast and resource efficient WebSockets.
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [10 June 2018 07:28 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/19 "2018-06-10T07:28:16Z")
NodeJS est-il vraiment singleThreaded ? Pas tout à fait on dirait. Y a crypto en exemple dans la vidéo.
Ignorez le fait que c’est un gars de Microsoft qui bosse sur un Mac pour promouvoir NodeJS.
Y a des gens bizarres partout.
En cherchant plus d’info, je suis tombé sur ce lien qui semble bien expliquer les particularités de l’Event Loop de NodeJS (gérée par la libuv).
[https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/](https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/)
Bref, bien connaître les subtilités de son langage et faire du profilage aide à optimiser les performances.
HS : On a les mêmes problématiques en Python : [https://www.youtube.com/watch?v=MCs5OvhV9S4](https://www.youtube.com/watch?v=MCs5OvhV9S4)
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [10 June 2018 09:06 UTC](https://forum.duniter.org/t/nodejs-vs-rust/4782/20 "2018-06-10T09:06:43Z")
> [@elois](#):
>
> et d’ailleurs les dev de bibliothèques Rust en on tenu compte
_Des_ développeurs, car je suppose que ce ne sont pas toujours les mêmes. Quand ils en tiennent compte c’est tant mieux, quand ce n’est pas le cas des optimisations sont possibles.
Quoi qu’il en soit dès qu’il y a du code intense en CPU non géré par du C++ asynchrone derrière, NodeJS est vite à la ramasse en comparaison de C++ ou Rust. Typiquement pour le calcul de WoT.
J’ai aussi le cas au niveau de la synchro, car je fais massivement des insertion dans Loki qui est du code JS pur. Certes la synchro est réalisée une seule fois et donc ce n’est pas si gênant (je descend à 30’ maintenant), mais c’est révélateur de limites à utiliser du JS synchrone. Pour être le plus performant possible, il faut en fait utiliser … le moins de JS possible. 🙃
[Next page](https://forum.duniter.org/t/nodejs-vs-rust/4782.md?page=2)