Migration du cœur de Duniter vers C++/TypeScript

Nodes
, , , ,
1

Je vous fait part ici d’une réflexion et d’une intention naissantes.

J’ai encore besoin d’y réfléchir et de recueillir vos avis, mais globalement, je pense qu’il serait intéressant de migrer une partie du code Duniter écrite en JavaScript vers C++.

À priori, cela commencerait par le cœur : c’est-à-dire la blockchain, son cycle de vie (empilement, dépilement de bloc), ses règles d’acceptation d’un nouveau bloc. Puis éventuellement d’autres éléments viendraient se greffer, tels la génération d’un nouveau bloc valide, la preuve de travail.

Il resterait quand même Node.js pour gérer l’aspect modules, communication réseau (où il excelle !), gestion des piscines, interface graphique, etc.

De sorte que la migration peut se faire progressivement.

Les raisons

1. Les outils

C’est tout bête, mais JavaScript ne dispose pas d’outils aussi puissants, variés et surtout libres que le C++. C’est un fait : si vous ne travaillez pas avec WebStorm, un IDE JavaScript propriétaire, alors coder Duniter fait l’effet d’être au pied d’une montage à gravir, pieds nus et sans connaissance des chemins à emprunter.

Avoir un débogueur et des outils d’analyse mémoire et CPU est une aide extrêmement préciseuse à notre niveau.

2. Le typage statique

C’est un reproche régulièrement fait à JavaScript que d’avoir un typage dynamique. C’est-à-dire qu’à aucun moment avant l’exécution, vous n’êtes certain de la nature de l’objet contenu dans une variable. On peut se retrouver avec un entier, une chaîne de caractère ou un objet complexe à tout instant.

Cela n’aide pas du tout les IDE à nous proposer les fonctions, méthodes, propriétés des objets manipulés. Donc il faut se souvenir de tout. C’est vraiment une plaie pour un nouveau venu, et même pour moi qui connaît bien le code je dépense inutilement de l’énergie à me rappeler de chaque élément.

Enfin, cela « rassure » de connaître à l’avance le type d’objet reçu. On n’a plus à douter de cela, juste qu’au pire l’objet peut être null, cas qu’il faut gérer. Cela évite bien des erreurs simples et libère l’esprit pour d’autres tâches.

3. Les contributeurs potentiels connaissent plutôt C++

C’est un fait : initialement OpenUDC a démarré avec 2 contributeurs en C++ (jbar, caner), puis Duniter a vu plusieurs contributions en C++ de @mmpio et maintenant @Beun, sans compter les développeurs déjà présents qui connaissent bien ce langage, par exemple @Inso. Et Il y en a certainement d’autres dont je ne connais pas l’affinité / le niveau avec C++.

Concernant Duniter en JavaScript, je crois que seul @inso a osé y toucher de façon conséquente.

Aussi historiquement, le logiciel Bitcoin est basé à 70% sur du C++. Tous ses dérivés suivent forcément cette ligne par inertie. Donc il y a une potentiellement une armée de développeurs en blockchain qui pourraient contribuer en C++ à Duniter.

Qui plus est, je suppose que les profils les plus enclins à toucher au cœur sont aussi des personnes qui cherchent à comprendre le fond et à maîtriser les détails. Or les langages répondant à ce niveau de maîtrise sont proches de la machine : le C++ paraît là encore être un bon candidat.

4. La crédibilité

Je trouve cet argument assez bête pour ma part, mais je l’entends régulièrement. : « JavaScript c’est pas sérieux », « C++ c’est un vrai langage ». Je croirais avoir à faire à des pseudo-scientifiques qui croient détenir la vérité, ou même à des économistes.

Mais bon, le fait est que ce sont des humains qui vont adopter la monnaie libre, et donc même si parfois leurs actions se basent sur des raisonnements douteux, on n’a pas besoin de rebuter ces humains avec JavaScript.

5. La vitesse d’exécution

Là aussi, je trouve l’argument léger, notamment car en C++ les opérations I/O, tels une lecture en base de donnée, sont bloquantes pour le thread courant. Les gains de performances obtenus dans le calcul sont perdues dans les opérations de lecture/écriture, sauf à jouer avec du multithreading, ce qui devient plus coton.

Mais après tout, si ce sont des extrémistes du C++ qui nous rejoignent, ce n’est pas tellement un problème.

Vous l’aurez donc compris, mon penchant pour le C++ tient surtout dans les points 1. à 3. Le reste c’est du bonus.

Vous en pensez quoi ?

6 Likes
2

J’en pense que tu vas nous ruiner en crowdfunding. :lol:

Les arguments entendus contre JavaScript existent et je ne suis pas en mesure de prendre position.
J’aime la diversité des écosystèmes, mais s’il s’agit de choisir entre un qui permet de rester libre et l’autre qui nécessite l’usage de modules privateurs, alors va pour le libre!
Surtout si cela favorise l’arrivée de nouveaux contributeurs.

1 Like
3

Salut. Ça fait un moment que je lis le forum mais je me suis inscrit pour répondre à ça…

Je suis d’accord que JS n’est pas génial comme langage, même s’il a l’avantage d’être facilement cross-platform et assez connu. Par contre, le C++… C’est un langage très complexe, qui est de pire en pire à chaque évolution (puisque de nouveaux mécanismes sont ajoutés au langage, le rendant donc encore plus compliqué). L’héritage, la surcharge d’opérateurs, les méthodes virtuelles rendent les programmes difficiles à comprendre pour les éventuels contributeurs. La compilation est très lente. Avoir à écrire et maintenir des fichiers d’entêtes en plus est ennuyeux. Il est “facile” de créer des bugs liés aux pointeurs, au dépassement de tableaux ou au multithreading.

Je voudrais suggérer de plutôt vous intéresser au Go. Il n’a peut-être pas encore le même support que le C++ au niveau des éditeurs et débuggers, mais il est très adapté à la création de logiciels réseau grâce à sa bibliothèque standard très complète, est BEAUCOUP plus simple que le C++, facile à apprendre pour quelqu’un qui connait déjà le C ou le Javascript, dispose d’un garbage collector, d’un détecteur de data races, de fonctionalités intégrées pour gérer les tests, compile très vite, n’a pas besoin de fichiers d’entêtes, etc.

Voilà :slight_smile:

4 Likes
4

Je soutiens totalement sur ce point, ainsi que pour l’aspect outils libres.

Là encore, je plussois. Héritier du système Oberon de Niklaus Wirth, sa vitesse de compilation est un vrai soulagement pour le développeur, de même que son garbage collector, sa vitesse d’exécution (langage compilé). Et il est libre (pour l’instant).

3 Likes
5

Pour ma part, il est vrai que je n’ai pas pu faire le saut pour contribuer au JavaScript de Duniter.
Le JS a l’avantage et l’inconvénient d’être écrit dans un langage interprété.
Le C++ va demander un niveau en programmation assez élevé de même que le Go.
Et le Rust est aussi dur que le C++ de ce qu’on m’a dit.

6

A chaud :

Le C++ vieilli effectivement mal et est source de nombreuses erreurs de sécurité du à sa complexité intrinsèque. (Dépassement de mémoire, de pile, etc, ce genre d’erreurs sont très courantes en C++ et sont la source de toutes les failles récentes).

Du coup je ne sais pas. J’entends l’argument, mais le C++ c’est pas vraiment un langage vers lequel je me dirigerai aujourd’hui :slight_smile:

Go, Rust, pourquoi pas. Mais ça demande un apprentissage important du fait que ces langages sont peu utilisés. Aussi, faire des modules compatibles node a l’air compliqué dans ces langages… Je ne suis pas certain que ça vaille le coup non plus.

Bref, pour l’instant je vais y réfléchir et sonder autour de moi…

2 Likes
7

Les points que je peux déjà éclaircir :

Concernant les modules Duniter :

  • il est toujours question d’utiliser Node.js qui reste l’enrobeur de tout le programme Duniter
  • écrire un module Duniter se fait et se fera toujours en JavaScript (d’ailleurs, il est n’est pas possible d’inclure un module C/C++ dans Duniter 1.3.x), tant que l’enrobeur reste Node.js

Concernant Go :

A noter que l’intérêt reste surtout d’améliorer les points 1. à 3., mais surtout selon moi les points 1. et 3… Le point 2. pourquoi pas, mais avant tout on doit pouvoir déboguer, et surtout avoir des contributeurs potentiels.

Car si cela nous mène à une nouvelle situation où je reste seul à coder, le C++ resterait une meilleure solution (ou même du C si vous préférez !).

4 Likes
8

Je vais peux-être dire une bêtise mais il y a aussi Python…

9

Il y aura le problème de typage libre en Python aussi il me semble, non ?

11

Mwarf, double passerelle, ça va pas être sympa à déboguer ça :slight_smile:

Sinon ya un mode de communication JSON direct entre module Go et NodeJS : https://www.npmjs.com/package/gonode … A tester

Ceci dit, in fine, on manquera toujours de développeurs puisque les développeurs Go sont surement encore plus rare que les développeurs Node ! :slight_smile:

La seule piste envisageable semble être le C++ si ta problématique est de toucher un panel de développeurs large avec un langage qui fasse “sérieux”… Mais le C++, en terme de productivité/sécurité/portabilité, c’est un peu l’horreur et ça demande une sacré rigueur !

1 Like
12

Go est vraiment le language qui a le vent en poupe, par contre attention, ce n’est pas un language orienté objet. En ceci, il impose de gérer des structures et plein de trucs qui en découlent.

Donc à part les afficionados du procédural, pour beaucoup de dev (dont je fais partie) c’est souvent une complexification supplémentaire.

Après il y a énormément d’outil autour, pour test, debug etc…
Et une énooooorme communauté.

2 Likes
13

Si l’objectif est de permettre l’ouverture à de nouveaux potentiels développeurs, je pense que ce n’est pas au développeur principal du code NodeJS de le faire pour des raisons d’économie d’énergie, de simplification et d’organisation.

Par ailleurs remarquons le fait que concernant bittorrent il existe justement déjà quantité de clients/serveurs différents (Qbittorrent, Transmission, peerTube, Vuze etc.) développés par des teams de développeurs différents.

Aussi l’approche de plus haut niveau et la plus ouverte consiste à nettoyer, préparer le chemin à de futurs développeurs, non pas en choisissant par les développeurs historiques quel langage utiliser pour de futurs serveurs Duniter, mais plutôt en rendant les données et le protocoles les plus simples et clairs possibles, de sorte qu’un nouveau serveur puisse être écrit correctement et sans erreur.

Cela me semble l’approche la plus efficace en terme d’investissement.

4 Likes
14

C’est ce que je m’applique à faire en ce moment. Je nettoie, je remets à plat, dans le but de faire des petits tutoriels introductifs au code Node.js de Duniter. Mais cela ne retire pas pour autant les problèmes 1. à 3. ! D’où ce post.

Ceci dit, en faisant des investigations pour Go aujourd’hui, je suis tombé sur des outils pour JavaScript également, notamment pour régler 1. (pouvoir déboguer avec des outils libres et efficacement). Le point 2. peut aussi être nuancé, mais pour le point 3. je suis bloqué ! Pourtant, JavaScript domine clairement en nombre de dépôts sur GitHub. On attend toujours les développeurs, peut-être finiront-ils par se montrer.

2 Likes
15

C’est un peu tôt. Un rapport d’étude membres / développeurs peut faire ressortir que au delà de 1000 membres ça devrait commencer à bouger frénétiquement…

1 Like
16

Un double binding, ça fait peut être trop. À voir.

N’y a t’il pas d’extensions Vim ou Emacs pour développer des langages bas niveau tels C, C++, Go, Rust ?

Je suis pas hyper fan des IDE car je les trouve lourds.
J’aimerais bien contribuer au cœur.

Je suis pas fan d’utiliser le Python pour le nœud. Ça facilitera les contributeurs, mais niveau optimisation, je pense pas que ça soit le plus adapté.

Tout à fait. Il n’y a pas de typage. C’est du typage dynamique comme en JavaScript.

Implémenter le protocole Duniter dans un autre langage risque disperser les efforts.
Concernant, les autres crypto-monnaies, il me semble pas qu’il y ait plusieurs implémentations de nœuds, mais uniquement des clients.
Concernant les nœuds, je pense que la maintenance est intense et demande de ne pas séparer les efforts sur deux implémentations. Même aujourd’hui le Bitcoin demande pas mal de maintenance de la seule implémentation du code logiciel nœud.

Il me semble que le projet de crypto-monnaie Hypeledger est écrit en Go.

2 Likes
17

Je confirme. C’est bien du Go.

18

Le Go est effectivement libre, par contre il y a un brevet déposé dessus.
Ça fait peu être un peu comme pour le mp3/4.

19

A titre personnel, l’approche de @Galuel me semble de très loin la plus robuste.

  • Duniter en tant qu’implémentation de référence est très bien : code accessible, portable, facile à maintenir et à débugger etc.
  • Il faut se concentrer sur la stabilité et la clarté de cette implémentation de référence
  • A terme, une seconde implémentation écrite dans un autre langage pourra alors être réalisée. La cohérence de fonctionnement vis à vis de Duniter pourra être vérifiée. Potentiellement, un jour, elle pourra remplacer les noeuds Duniter.

Pour info, c’est comme ça qu’a été réalisé le projet Matrix. Une implémentation de référence en python, et d’autres noeuds développés dans d’autre langages ( en Rust , en Go )…

Je propose :

  • De décrire Duniter comme “Implémentation de référence du protocole de blockchain DUP”
  • De décrire Ğ1 comme étant l’instanciation de la première monnaie libre construire sur le protocole blockchain DUP
  • De laisser à d’autres dev l’initiative de développer Duniter dans un autre langage qui leur plairait :slight_smile: Avec l’implémentation de référence, c’est quand même beaucoup plus simple qu’en partant de 0.
6 Likes
20

Bonjour,

J’espère ne pas arriver après la bataille.

Quand j’ai lu le post de @cgeek, tous les voyants d’alertes se sont allumés : “gros changements = risques de bug / de régression, etc.” (sans parler de la charge de travail que cela induit).

En conséquence, passer à un autre langage… Pourquoi pas mais il faut vraiment vérifier/valider les raisons qui rendent ce changement nécessaire.

Aux 5 raisons expliquées par @cgeek, j’ai envie d’ajouter une question : est-ce que le code actuel en Node.js peut supporter une montée à l’échelle ? (communauté à 10^5 ou 10^6 membres avec les volumes importants de transactions que cela induit).

On peut poser la question autrement : avez-vous connaissance de projets de même envergure implémentés en Node.js ?

Si ce n’est pas le cas, cela peut constituer un argument supplémentaire pour procéder à un changement de langage même si j’ai bien conscience toutefois que la communauté n’a pas atteint ces effectifs aujourd’hui.

Pour préciser les choses également : de quel volume de code parle-t-on (grossièrement) ?

Si j’ai bien compris, ce code constitue le “cœur du réacteur”. Il est donc particulièrement sensible ?

1 Like
21

Atom, que je citais plus haut, n’est pas un IDE. C’est plutôt un éditeur de texte extensible. Il est possible de lui ajouter des fonctionnalités de debug Go / Node.js en 3 clics.

Non non, tout cela est encore en phase de réflexion :slight_smile:

Il y a plusieurs strates. Disons que le cœur blockchain fait 2000 lignes environ. Puis selon le niveau visé, on pourrait dire que le cœur va jusqu’à 10.000 lignes de code environ.

Après il y a l’enrobage général, la gestion des modules, piscines, etc., où l’on arrive vers les 20.000 lignes. Mais ce code là n’a pas à être migré.

Donc on parle de 10.000 lignes de code environ, à migrer progressivement.

Il n’y a rien d’urgent, je suis pour l’instant en plein travaux de nettoyage et de simplification des éléments écrits en JS, et je prépare aussi une vidéo d’installation de l’environnement de développement pour s’y mettre facilement. Peut-être qu’on n’aura pas besoin de migrer le cœur après tout, mais pour l’instant les contributions en JS sont très limitées !

1 Like