Discussion :

[mister3957]

Question pour les gens qui font du Node, c'est jouable d'intégrer un appel asynchrone à un module codé en C/C++ sans bloquer l'event loop ?

Yep ! NodeJS peut communiquer avec du natif, le tout en asynchrone. Ainsi si tu as besoin de puissance, de calculs, de MT, tu le fais en C/C++ et avec 2/3 pauvres bindings tu pilotes dans du JS, en callback ou promesse, pour ma part j'ai choisit les promesse. Ça va aussi pour réexploiter les bibliothèques natives.

Deux cas d'exploitation dans ma boîte :
- On taffe dans la logistique, qui demande des calculs complexes et beaucoup de puissance. Le moteur on l'a fait en C/C++, le reste en JS (parce que la plomberie en C/C++, non merci, on s'est trop pété les dents et au bout d'un moment ça suffit)
- Y'a peut de temps on a dû communiquer avec IBM MQ Series, version 7.5, imposé par l'hébergeur, version qui ne propose qu'une API en C. Pas de problème, en 1 jour les bindings étaient faits pour Linux, 3 jours pour les différentes archis visées (arm, arm64, x86, x64 etc.)

Et encore, c'est parce que personne n'avait poussé le truc sur npmjs, sinon on se serait encore moins emmerdé.

Du coup plus besoin d'un machin ultra lourd tel que JAVA, des compétences rares et hors de prix pour C/C++ et le TTM s'est vu grandement amélioré, donc les sous sous aussi, même si le coeur et la VA de ce que l'on produit est fait en C/C++.

C'est juste excellent ce couplage devenu possible, très simplement, très légèrement

[sekaijin]

Je ne suis pas tout à fait d'accord avec l'analyse qui est faite.

Je ne sais pas comment on peut dire qu'un langage est plus "puissant" qu'un autre. pour moi il n'ont pas la même couverture expressive.

JavaScript a dans cette affaire une caractéristique qui est particulièrement utile. le fait de gérer nativement la programmation événementielle (réagir à des événements peut importe les noms qu'on donne à la chose).

on peut très bien implémenter une telle programmation en C et même en assembleur. Alors Passer de C/C++ à Javascript pour une application essentiellement événementielle
c'est juste choisir un langage qui porte nativement cette fonctionnalité à la place de l'implémentater.
dans ce sens c'est passer à un langage plus "puissant".

ReactiveC++ aurait été n choix tout aussi pertinent. et bien d'autre aussi.

Il y a aussi dans cette affaire le passage du compilé statique au compilé à la volée. (Aujourd'hui tous les langages interprétés ou presque utilisent un compilateur à la volé et une machine virtuelle). qu'on soit d'accord où pas il est une chose qui est certaine c'est que les deux ont des avantages et des inconvénients.

La question à se poser dans le choix est "quelle utilité ?" Si c'est utile pour l'application dans quelle mesure. (il est bien plus facile de faire de l'auto-programmation avec un langage interprété) pour répondre il suffit de mettre les avantages et les inconvénients de tous les langages candidats de pondérer le critère en fonction de absolument nécéssaire, nécessaire, un plus, pas nécessaire. et ça aide à y voir clair.

le dernier point est la nature des objets (en tant que structure) manipulés. Si on manipule des objets à la définition stricte peu ou pas évolutive les langages fortement structurés ont été pensé pour ça. Si on manipule des structures au contours vague et changeant les langages portant nativement de telles définitions de structures seront mieux adapté. là encore les deux ont des avantages et des inconvénients et il convient de les évaluer pour faire un choix pertinent.


Et pour finir il y a un facteur que je pense on oubli un peu trop. Les compétences. Mieux vaut utiliser un langage maitrisé et moins bien adapté qu'un langage parfaitement adapté mais inconnu. La disponibilité des compétences sur le marché sont aussi un facteur qui doit entrer dans le choix. aujourd'hui où tout va très vite on oublie un peut trop que certaines applications fonctionnent depuis 40 ans. et je sais par expérience que ce qu'on pensait pérenne sont porte depuis longtemps et d'autre qu'on disait provisoire sont là depuis des décennies. Alors choisir un langages ésotériques connu d'une poignée d'aficionados, c'est prendre le risque de devoir dépenser des sommes astronomique pour maintenir la chose. Même en choisissant des langages répandus, le temps fait que les compétences disparaissent. (on cherche des développeur COBOL aujourd'hui).

Alors plus que le fait d'avoir réécrit git ce qui serait intéressant c'est d'avoir l'analyse qui a mené à ce choix.
A+JYT

[Shepard]

Selon les stats Github, l'intérêt porté dans les projets javascript est fortement à la baisse ces 5 dernières années (bien qu'il reste le plus "tendance"):



https://madnight.github.io/githut/#/stars/2018/1

[blbird]

Une "tendance"? Il fait plus que tous les autres cumulés. Sacré tendance tu me diras dit-donc!

[Shepard]

Je trouvais ce graphique pas mal par rapport au sujet ^^

En 2012 JS avait plus de 50% de l'attention sur github, c'est vrai que c'est impressionnant !

[Invité]

S'il vous plait arrêtez de citer nodejs et electron pour "prouver" les qualités de javascript. Nodejs c'est essentiellement v8 (60% en C++) + libuv (95% en C). Pareil pour electron (70% en C++).

Quant aux nombreux packages JS sur github ce n'est pas du tout un avantage mais une conséquence de l'absence de lib standard.

[blbird]

S'il vous plait arrêtez de citer nodejs et electron pour "prouver" les qualités de javascript. Nodejs c'est essentiellement v8 (60% en C++) + libuv (95% en C). Pareil pour electron (70% en C++).

Quant aux nombreux packages JS sur github ce n'est pas du tout un avantage mais une conséquence de l'absence de lib standard.

C++ doit être écrit en grande partie en C et en assembleur, et le C lui-même doit bien être écrit en assembleur. Ca n'enlève en rien l'intérêt du C++ ou du C en comparaison de l'assembleur, heureusement.

Je doute qu'il existe un seul langage qui ait toutes les librairies Github disponibles nativement, ni en quoi avoir beaucoup de librairies, qu'elles soient natives ou non, est un problème? Cela montre bien que l'intérêt et les développeurs sont là.

[Pyramidev]

C++ doit être écrit en grande partie en C et en assembleur, et le C lui-même doit bien être écrit en assembleur.

C et C++ ne sont ni des logiciels, ni des bibliothèques, mais des normes écrites en anglais.
Les trois compilateurs C++ les plus connus sont GCC, MSVC et Clang. Ils sont tous les trois codés en C++ et savent compiler à la fois du C et du C++.

[blbird]

Je ne vois vraiment pas ce que cela change, et encore moins l'intérêt de venir nous dire que le JS tourne sous un navigateur (ou un moteur de navigateur) qui est codé en C/C++.

Chrome, Electron et Node utilisent le "Google V8 JavaScript Engine", qui est codé en C/C++, oui et alors? Derrière, on développe en JS, et il faut bien un moteur pour faire tourner le langage, comme tous les autres langages. De même, tout code JS qui tourne sous un navigateur, utilise le moteur JS du-dit navigateur qui est lui-même certainement à la base codé aussi en C++ (Firefox et autres), qu'est-ce que ca change?

Et pour les compilateurs C/C++, d'ailleurs comme la plupart de tous les autres langages importants, le premier compilateur simple est bien souvent en assembleur. Ensuite seulement, le langage réécrit les versions de compilateur suivantes avec son propre nouveau langage basé sur ce premier compilateur.

On est dans un système de fonctionnement par couches, c'est le même principe avec "Google V8 JavaScript Engine" ou avec n'importe quel autre langage ou compilateur. Ils proviennent tous, à la base, de l'assembleur. Et presque tous, ensuite, de code C/C++. Ce qui n'enlève rien aux qualités des moteurs de compilation/exécution de JS, du langage JS en lui-même, d'Electron, de Node ou de n'importe quel moteur/framework/librairie JS.

[Marco46]

S'il vous plait arrêtez de citer nodejs et electron pour "prouver" les qualités de javascript. Nodejs c'est essentiellement v8 (60% en C++) + libuv (95% en C). Pareil pour electron (70% en C++).

En quoi c'est un argument ça ? Quel autre langage de haut niveau est écrit avec autre chose que du C/C++ ?!?

Si tu pouvais développer cet argument stp ...

Quant aux nombreux packages JS sur github ce n'est pas du tout un avantage mais une conséquence de l'absence de lib standard.

Ce n'est pas comparable. Le développement web évolue plus vite et est plus jeune que le développement système et il est contraint par l'évolution des navigateurs qui sont les verrous des nouveautés (il faut 2 implémentations d'une nouvelle feature du langage en prod pour la valider définitivement). Il ne peut pas y avoir un équivalent ce n'est pas le même sujet.

Et je ne crois pas qu'on puisse encore répondre à la question de savoir si cette vitesse d'évolution est due à la jeunesse ou bien est structurelle du fait du sujet (le web).

Ton problème c'est que tu prends la grille de lecture du développement système pour lire le développement sur le web. C'est une erreur.

[Pyramidev]

Et pour les compilateurs C/C++, d'ailleurs comme la plupart de tous les autres langages importants, le premier compilateur simple est bien souvent en assembleur. Ensuite seulement, le langage réécrit les versions de compilateur suivantes avec son propre nouveau langage basé sur ce premier compilateur.

De nos jours, coder un compilateur en assembleur serait une idée farfelue. Pourquoi programmer un compilateur en assembleur alors que ce serait beaucoup plus pratique de le coder en C, en C++, en D ou n'importe quel autre langage de plus haut niveau que l'assembleur et qui permet d'écrire un programme qui a une bonne vitesse d'exécution ?

Quand un compilateur compile du langage X vers le langage machine, si un tel compilateur est capable de générer un programme qui s'exécute relativement vite, alors le code source peut être entièrement réécrit en X. Sinon, le code source reste dans un langage comme C ou C++.

[blbird]

De nos jours, coder un compilateur en assembleur serait une idée farfelue. Pourquoi programmer un compilateur en assembleur alors que ce serait beaucoup plus pratique de le coder en C, en C++, en D ou n'importe quel autre langage de plus haut niveau que l'assembleur et qui permet d'écrire un programme qui a une bonne vitesse d'exécution ?

Complètement d'accord avec toi.

Mais ce n'est pas parce que la plupart des compilateurs JS, ou même que certaines librairies sont écrites dans un autre langage que le Javascript, que c'est un problème. C'est plus ou moins le cas pour tous les langages. Et ce n'est pas pour ca que ces langages ne sont pas des langages de "qualité".

[Invité]

Quel autre langage de haut niveau est écrit avec autre chose que du C/C++ ?!?

Beaucoup en fait : crystal, go, haskell, java, python, perl6, rust, scala... (https://en.wikipedia.org/wiki/Bootstrapping_(compilers))

Ce n'est pas la qualité de JS qui l'a rendu populaire. JS a d'abord été populaire avec le web frontend et c'est ensuite que sont apparus les normes et outils de qualité.

[psychadelic]

La question n’est pas de démontrer une quelconque supériorité dans la syntaxe ou je ne sais quoi du langage JavaScript, cela n’a aucun intérêt.

S'il vous plait arrêtez de citer nodejs et electron pour "prouver" les qualités de javascript. Nodejs c'est essentiellement v8 (60% en C++) + libuv (95% en C). Pareil pour electron (70% en C++).
Quant aux nombreux packages JS sur github ce n'est pas du tout un avantage mais une conséquence de l'absence de lib standard.

Parler de NodeJS ou d’Electron est juste utile pour montrer que le JavaScript ne se cantonne pas à de petits scripts présents sur des pages html, parce qu’évidement, il existe encore des irréductibles pour jeter un regard dédaigneux sur ces possibilités, vu qu’ils ont l’air plutôt agacé de voir toute cette agitation autour de ce Langage.

Quand aux librairies, c’est vrai qu’il y en a pléthore, avec tout de même quelques ténors comme Angular ou de React qui fédèrent un peu les pratiques.

Le gros avantage, c’est qu'au moins on à l’embarras du choix*; j’ai travaillé avec des librairies C++ «*maison*» ou même «*corporate*» dans le milieu de la finance, et tout n’est pas forcément formidable, loin de la, quand à changé une virgule quelque part, c’est aller au suicide professionnel*; alors que c’est l’inverse dans les librairies open source*: il y a toute une émulation, et s’il y a critique, elle est faite par des pairs et ne sont pas noyautés par une hiérarchie frileuse et incompétente.

Et bien sur, cerise sur le gâteau de JavaScript, il est beaucoup plus souple et plus économique à déployer et à maintenir sur Mainframe, et quand on parle d’argent, forcément…

Alors il y a eu un effet de raz de marée coté outre-Atlantique, et qui arrive, en décalage, comme une grosse vague aujourd’hui en Europe.
Bien sur il y a eu d’abord des excès car la maturité prend du temps, les millions de modules dans NPM finiront par s’autoréguler et il ne restera que les meilleurs, mais en attendant ç’a été, ( c’est encore) une formidable pépinière de talents, d’inventivité et de créativité tout azimuts, car il ne faut pas oublier non plus l’arrivée de la robotique dont les circuits Arduino en sont l’étendard, ainsi que celle de l’Internet des Objets*; et La JavaScript s’y révèle comme incontournable, alors que les systèmes en C ou C++ y sont vraiment à la ramasse.

Au final, derrière le "sigle" JavaScript, on à affaire à un nouvel univers informatique, sans doute le plus vaste de tous et dont la croissance est loin d'être achevée.

[fredoche]

C et C++ ne sont ni des logiciels, ni des bibliothèques, mais des normes écrites en anglais.

https://www.ecma-international.org/p...s/Ecma-262.htm
Étonnamment ECMAScript est un langage normé supporté par une organisation internationale.
Des moteurs, interpréteurs comme V8, Rhino ou Spidermonkey,... n'ont pas d'autre but que de rendre fonctionnels les éléments de cette norme.

[Marco46]

Beaucoup en fait : crystal, go, haskell, java, python, perl6, rust, scala... (https://en.wikipedia.org/wiki/Bootstrapping_(compilers))

Ce n'est pas la qualité de JS qui l'a rendu populaire.

Donc ton argument c'est de dire que le JavaScript n'est pas de bonne qualité parce que ses moteurs ne sont pas écrits avec JavaScript ?

JS a d'abord été populaire avec le web frontend et c'est ensuite que sont apparus les normes et outils de qualité.

Non le point de bascule c'est Node.js en 2009 (sortie concomitante avec ES5) qui a permis l'éclosion d'un écosystème et la création de tous les outils autour. Avant ça on était vraiment dans la bidouille.

Comme quelqu'un d'autre l'a rappelé, les normes existent depuis presque le début de l'existence du langage. Après vérif la première version de JavaScript (version Netscape par Brendan Eich) c'est fin 1995, la première version de la norme ECMA-262 c'est juin 1997. Donc bon ... Ça fait un bail que c'est normé.

[Invité]

Donc ton argument c'est de dire que le JavaScript n'est pas de bonne qualité parce que ses moteurs ne sont pas écrits avec JavaScript ?

S'il te plait, lis les messages au lieu de t'auto-enflammer : je n'ai jamais dit que JS n'est pas de bonne qualité.

Et pareil pour les normes : personne n'a dit que JS n'avait pas de norme. Pyramidev a juste dit que C++ est une norme de langage et non un logiciel.

[fredoche]

bah à mes débuts, on faisait du Javascript aussi coté serveur avec l'ASP classic (Jscript). Pas très couru en face de VBscript, mais moi ça me sert encore aujourd'hui.

Et Je crois que Netscape avait aussi un produit coté serveur qui tournait en Javascript.

Coté bidouille je veux bien mais déjà en 2000, j’étais support technique chez HP Grenoble pour l'installation d'un produit dénommé Backweb sales accelerator, qui implémentait déjà les principes d'une SPA, et où le DOM était entièrement manipulé en Javascript pour la construction de l'interface.

Mais c'est vrai qu'à cette époque les clients lourds et les langages qui allaient avec étaient la norme.

[Jitou]

Tant qu'on fera du soft jetable, du front pour l'essentiel en Javascript le principe de Tim Berners Lee sera appliqué à bon escient car plus personne ne fait évoluer un soft écrit en JS, le plus souvent après quelques années on jette et on recommence, éventuellement avec le nouveau framework js tendance du moment !

[Marco46]

Encore un commentaire qui n'a aucun rapport avec le js. On peut faire n'importe quoi n'importe comment avec n'importe quel langage ou outil. Si des gens ont le pognon pour coder n'importe comment, ne pas investir dans leurs tests et réécrire tout à chaque changement de techno majeure ou évol fonctionnelle majeure c'est leur problème mais je ne pense pas que ça soit la majorité des cas, il y a globalement peu d'entreprises qui ont ce genre de moyens.