L'auteur express TJ fait ses adieux à Node.js et se dirige vers Go_node.js

Tout d'abord, il s'agit d'un article traduit de Farewell Node.js de TJ. J'ai été vraiment choqué après avoir lu cet article, mais je ne suis pas d'accord avec certains points de vue de l'auteur. Par exemple, je pense au package Node js. s'inscrire est l'un de ses nombreux avantages, mais Go manque légèrement sur cet aspect. En raison de mes limitations personnelles, il y avait beaucoup de choses que je n'ai pas comprises lors de la traduction. Je suis également allé sur le blog de l'auteur et sur stackoverflow pour poser quelques questions et obtenir des réponses. Il y a encore de nombreuses imperfections dans la traduction, et j'espère que vous pourrez obtenir quelques indications.

PS. En tant que débutant dans Node.js, je voudrais remercier TJ pour son travail acharné et bon voyage.

Texte :

Adieu Node.js

Quitter le domaine Node.js

Je me bats avec Node.js en production depuis assez longtemps, et malheureusement maintenant que je n'aime plus faire ce travail, du moins pour le moment, c'est mon adieu officiel. Plus important encore, j'ai besoin de mainteneurs.

Node est génial à certains égards, mais ce n'est pas le bon outil pour le type de logiciel qui m'intéresse ces jours-ci. Je prévois toujours d'utiliser Node pour le site Web, mais si vous souhaitez maintenir des projets, laissez simplement un commentaire avec votre nom d'utilisateur Github, votre nom d'utilisateur npm et le nom du projet pour me le faire savoir. Habituellement, tout ce que je demande, c'est de ne pas modifier complètement l'API existante. Si vous voulez vraiment faire cela, il est préférable de démarrer un nouveau projet.

Koa est un projet que je continuerai à entretenir. (Avec Co et amis)

L'histoire du Saint Graal

J'ai toujours aimé le C, mais tous ceux qui travaillent dans le développement C savent qu'il est précieux mais sujet aux erreurs. Il est difficile de justifier le choix d'une langue dans le travail quotidien, car ce n'est pas exactement la langue la plus rapide pour le travail. La simplicité est aussi la raison pour laquelle elle est toujours louée, mais vous n'irez pas très loin sans une tonne de modèles.

À mesure que je m'implique davantage dans le développement de systèmes distribués, la tendance selon laquelle les performances des nœuds sont supérieures à la disponibilité et à la robustesse me rend de plus en plus frustré. Au cours de la semaine dernière, j'ai réécrit un système distribué relativement volumineux dans Go pour le rendre plus robuste, plus performant et plus facile à maintenir, et comme le code synchrone est généralement plus élégant et plus facile à développer, il offre une meilleure couverture testable.

Je ne dis pas que Go est le Saint Graal, ce n'est pas parfait, mais pour de nombreuses langues qui existent aujourd'hui, Go est pour moi une excellente réponse. À mesure que de plus en plus de langages de « nouvelle génération » comme Rust et Julia trouveront leur place et mûriront, je suis sûr que nous aurons d'autres solutions intéressantes.

Personnellement, je suis très enthousiasmé par le langage GO en raison de sa vitesse itérative. J'étais très excité de les voir impatients d'atteindre la version 2.0, et d'après les nouvelles que j'ai entendues, ils n'ont pas eu peur et ont cassé les grandes choses originales. J'adorerais que cela soit vrai, principalement parce que je pense que si c'est vraiment bon pour la langue, cela devrait rapidement briser les choses existantes. Mais je ne suis pas non plus un géant du logiciel qui gère de nombreux systèmes. :D

Éditeur : J'ai dû mal interpréter certaines des soumissions à la liste de diffusion ; ils n'étaient pas désireux d'apporter des modifications majeures à tout moment ; @enneff

Pourquoi y aller ?

Si Node fonctionne pour vous et que vous n'avez rien à craindre, cela reste un excellent outil. Mais si quelque chose vous dérange, n'oubliez pas de sortir de vos sentiers battus et de voir ce qu'il y a en dehors des sentiers battus : dès les premières heures de création d'un produit avec Go, j'étais déjà accro.

Encore une fois, je ne dis pas que Go est le meilleur langage absolu et que vous devez l'utiliser. Mais il est très mature et fort pour son âge. (À peu près quand j'avais le même âge que Node). La refactorisation de types est simple et amusante, les outils de travail et de débogage fournis par Go sont excellents et la communauté a des réglementations très strictes en matière de documentation, de formats, de benchmarks et de conception d'API.

Étant tellement habitué à l’extrême modularité de Node et ayant expérimenté la bibliothèque standard pourrie de Ruby, lorsque j’ai entendu parler de Go pour la première fois, j’ai trouvé sa bibliothèque standard horrible. Après avoir approfondi ce langage, j'ai réalisé que la plupart des bibliothèques standard à ce stade sont très nécessaires, telles que la compression, json, IO, buffered IO, les opérations sur les chaînes, etc. La plupart de ces API sont bien définies et puissantes. Il est facile d’écrire des programmes entiers simplement en utilisant ces bibliothèques standards.

Forfaits Go tiers

La plupart des bibliothèques Go se ressemblent et la plupart du code tiers que j'ai utilisé jusqu'à présent est de haute qualité, ce qui est difficile à trouver dans Node car JavaScript attire des développeurs de différents niveaux de compétence.

Pour les forfaits Go, il n'y a pas de centre d'inscription, vous voyez donc généralement 5 ou 6 forfaits identiques en même temps. Cela peut parfois créer une certaine confusion, mais cela a pour effet secondaire intéressant que vous deviez examiner attentivement chaque package pour décider quelle est la meilleure solution. Par Node, il existe généralement des packages canoniques comme "redis", "mongodb-native" ou "zeromq", vous vous arrêterez donc là et en déduisez simplement qu'ils sont les meilleurs.

Si vous effectuez un travail distribué, vous constaterez que les impressionnants types de données de base de concurrence de Go sont très utiles. Nous pouvons réaliser quelque chose de similaire avec les générateurs dans Node, mais à mon avis, les générateurs ne représentent que la moitié du travail. Sans gestion indépendante des erreurs, la pile de reporting reste, au mieux, banale. Quand ces solutions fonctionnent bien, je ne veux pas attendre trois ans pour que la communauté se réorganise.

À mon avis, la gestion des erreurs de Go est exceptionnelle. Node est génial dans le sens où vous devez considérer chaque erreur et décider quoi faire. Cependant, Node échoue à :

Vous pouvez effectuer des rappels à plusieurs reprises

Vous ne pouvez pas effectuer de rappels du tout et vous perdre dans un état instable (par exemple, si vous oubliez de transmettre un rappel de gestion des erreurs, lorsqu'une erreur se produit, Node avalera l'erreur sans aucun retour)

Vous pouvez recevoir des erreurs prêtes à l'emploi

les émetteurs peuvent recevoir plusieurs événements erronés

Oublier la mauvaise gestion des événements va tout gâcher

Souvent incertain de ce qui doit être mal fait

La gestion des erreurs est très redondante

Les rappels sont nuls
Dans Go, lorsque mon code se termine, il se termine et vous ne pouvez pas le réexécuter dans l'instruction. Dans Node, cela n'est pas défini. On pourrait penser qu'un programme est complètement exécuté jusqu'à ce qu'une bibliothèque appelle accidentellement un rappel plusieurs fois, ou ne parvienne pas à effacer correctement les gestionnaires et provoque la nouvelle exécution du code. Il est assez difficile de trouver ces raisons dans le code de production réel, alors pourquoi s'embêter ? Les autres langues ne vous font pas subir cette douleur.

Nœud du futur

J'espère toujours que Node se porte bien et que beaucoup de gens y investissent massivement, il a un tel potentiel. Je pense que Joyent et l'équipe doivent se concentrer sur la convivialité : les performances n'ont aucun sens si votre application est fragile et difficile à déboguer, refactoriser et développer.

Le fait que nous aurons encore cette vague erreur "Error: getaddrinfo EADDRINFO" dans 4-5 ans nous indique où sont les priorités de développement de Node. Naturellement, il est facile de passer à côté de ces éléments lorsque vous vous concentrez sur la construction du cœur du système. Je pense que les utilisateurs ont exprimé à maintes reprises leurs opinions sur ce genre de choses sans voir aucun résultat. Nous recevons généralement une poignée de réponses aux affirmations selon lesquelles ce que nous avons est déjà parfait. En pratique, ce n’est pas le cas.

Les flux sont interrompus, les rappels ne sont pas faciles à utiliser, les erreurs ne sont pas claires et les outils ne sont pas faciles à utiliser. Il existe des réglementations communautaires, mais elles font défaut par rapport à Go. Malgré cela, je peux continuer à utiliser Node pour certaines tâches spécifiques, telles que la création de pages Web, ou certaines API ou prototypes dispersés. Si Node peut résoudre certains de ses problèmes fondamentaux, il a une chance de rester pertinent, mais l'argument en faveur des performances plutôt que de la disponibilité ne va pas très loin lorsqu'il existe une alternative offrant à la fois des performances et une disponibilité plus élevées.

Si la communauté Node décide d'adopter des générateurs et de les implémenter dans une partie très centrale de Node, et de propager correctement les erreurs, il y a une chance que cela puisse être référencé. Cela améliorera considérablement la disponibilité et la robustesse de Node.

La bonne nouvelle est qu'il y a quelque temps, j'ai parlé avec les gars incroyables et talentueux qui contribuent au code de base de StrongLoop. Ils adoptent une approche claire en écoutant les réponses des développeurs à la plate-forme et prévoient de trouver le bon moyen de résoudre ces problèmes afin de faciliter l'utilisation de Node à l'avenir. Je ne sais pas comment se terminera le conflit sur le développement simultané de pièces principales par plusieurs sociétés, mais j'espère que le côté axé sur les développeurs l'emportera.

Ce n’est pas censé être une attaque personnelle, il y a beaucoup de personnes vraiment talentueuses qui travaillent avec ou sur Node, mais ce n’est plus ce qui m’intéresse. J'ai passé de très bons moments au sein de la communauté Node et rencontré des personnes vraiment intéressantes.

La morale de l’histoire est la suivante : ne vous limitez pas à votre propre cercle ! Découvrez ce qui est disponible ailleurs et vous pourrez peut-être à nouveau profiter de la programmation. Il existe tellement de bonnes solutions que j’ai fait l’erreur d’attendre trop longtemps pour jouer avec !