Apprendre Erlang vs apprendre node.js [fermé]

Je vois beaucoup de conneries en ligne sur la façon dont Erlang donne un coup de pied au cul de node.js dans à peu près toutes les catégories imaginables. J'aimerais donc apprendre Erlang et essayer, mais voici le problème. Je constate que j'ai beaucoup plus de difficulté à récupérer Erlang qu'à node.js. Avec node.js, je pouvais choisir un projet relativement complexe et en une journée, quelque chose fonctionnait. Avec Erlang, je me heurte à des obstacles et je ne vais pas aussi vite.

Alors .. pour ceux qui ont plus d'expérience, Erlang est-il compliqué à apprendre ou manque-t-il quelque chose? Node.js n'est peut-être pas parfait, mais il semble que je puisse faire avancer les choses.

Tout d’abord, je suis d’accord avec la réponse de JUST MY OPINION concernant l’apprentissage d’Erlang. C'est un langage essentiellement fonctionnel (bien que la simultanéité joue un grand rôle), et toutes ses fonctionnalités ont été ajoutées pour aller vers la tolérance aux pannes et la robustesse, ce qui n'est pas exactement le même objectif de conception que Javascript.

Deuxièmement, laisser Node.js entrer dans Erlang est un peu mal placé. Node.js est un serveur / framework unique qui permet de tout faire de manière événementielle à l'aide de callbacks. Erlang a son propre cadre (OTP), mais ce n’est pas du tout au même niveau.

Si vous envisagez d'apprendre Erlang, je suggère dans mon billet une lettre ouverte au débutant d'Erlang (ou spectateur) comme lecture d'introduction avant de plonger dans des didacticiels.

La seule chose dans laquelle vous pouvez comparer Erlang et Node.js, en termes de modèles et d'utilisation, est la manière dont ils sont gérés par les événements. Cependant, il y a deux grandes différences majeures ici. Le modèle de Node.js est basé sur des rappels liés à des événements. Erlang est basé sur les files de messages et les réceptions sélectives. Quelles sont les implications ici?

Tout d'abord, si vous faites les choses à la manière d'un rappel, la seule façon de véhiculer un état est de le généraliser ou de l'introduire dans une programmation de type poursuite. Deuxièmement, vous devez vous occuper de la matrice complète de l'événement. Un exemple de ceci est que si nous imaginons une machine à états finis très simple: un sémaphore mutex, piloté par les événements.

Le sémaphore mutex a deux états: verrouillé et libre. Chaque fois qu'une unité de calcul donnée (ouvrier, processus, fonction ou thread) veut accéder au mutex, elle doit déclencher un événement qui lui dit "je suis intéressé". Maintenant, vous devez prendre en charge les types d'événements suivants:

• Le mutex est gratuit et vous demandez d'obtenir le verrou
• Le mutex est verrouillé par quelqu'un d'autre et vous voulez obtenir le verrou
• Le mutex est verrouillé par vous-même et vous voulez le libérer.

Ensuite, vous avez d'autres événements à prendre en compte, tels que le dépassement de temps pour éviter les blocages:

• Le mutex a été verrouillé et vous avez attendu trop longtemps, une minuterie pour arrêter les feux
• Le mutex a été verrouillé et vous avez attendu trop longtemps, vous avez obtenu le verrou puis le délai d’attente s'est déclenché.

Ensuite, vous avez également les événements hors limites:

• vous venez de verrouiller le mutex alors qu'un travailleur s'attendait à ce qu'il soit libre. Maintenant, la requête de ce travailleur doit être mise en file d'attente de sorte que, lorsqu'elle est libre, elle soit traitée en retour
• Vous devez rendre tout le travail asynchrone

La matrice d'événements devient très rapide. Notre FSM ici n'a que 2 états. Dans le cas de Erlang (ou de toute langue avec réception sélective et asynchrone avec des événements potentiellement synchrones), vous devez vous soucier de quelques cas:

• Le mutex est gratuit et vous demandez d'obtenir le verrou
• Le mutex est verrouillé par quelqu'un d'autre et vous voulez obtenir le verrou
• Le mutex est verrouillé par vous-même et vous voulez le libérer.

Et c'est tout. Les minuteries sont traitées dans les mêmes cas que la réception, et pour tout ce qui concerne l'attente de la gratuité, les messages sont automatiquement mis en file d'attente: le travailleur doit seulement attendre une réponse. Le modèle est beaucoup, beaucoup plus simple dans ces cas.

Cela signifie qu'en général, les modèles CPS et basés sur le rappel, tels que celui de node.js, vous demandent soit d'être très intelligent dans la gestion des événements, soit de prendre en charge l'intégralité d'une matrice d'événements complexe, car vous devez être rappelé pour chaque cas sans conséquence résultant de problèmes de synchronisation et de changements d'état étranges.

Les réceptions sélectives vous permettent généralement de vous concentrer uniquement sur un sous-groupe de tous les événements potentiels et vous permettent de raisonner beaucoup plus facilement à propos des événements dans ce cas. Notez que Erlang a un comportement (implémentation de modèle de conception / framework) appelé quelque chose gen_event. L'implémentation de gen_event vous permet d'avoir un mécanisme très similaire à ce qui est utilisé dans node.js si c'est ce que vous voulez.

Il y aura d'autres points qui les différencient; Erlang a une planification préemptive tandis que node.js le rend coopératif, Erlang est plus apte à certaines applications à très grande échelle (distribution et autres), mais Node.js et sa communauté sont généralement plus aptes au Web et mieux informés des dernières tendances du Web. C'est une question de choix du meilleur outil, et cela dépendra de vos antécédents, de votre type de problème et de vos préférences. Dans mon cas, le modèle d'Erlang correspond très bien à ma façon de penser. Ce n'est pas nécessairement le cas pour tout le monde.

J'espère que cela t'aides.

Erlang n'est pas compliqué à apprendre, il est tout simplement étranger à l'esprit que Chambers Constant (99,44%) des programmeurs a appris comment fonctionne la programmation. Le problème auquel vous faites face est probablement une simple désorientation conceptuelle plutôt qu'une complexité réelle.

Voici quelques-unes des fonctionnalités étranges d'Erlang qui vont piquer un programmeur typique:

• Erlang est un langage de programmation (principalement) fonctionnel. Les langages de programmation les plus courants sont presque impérativement militants.
• Le modèle de concurrence d'Erlang est le modèle d'acteur. Les langages de programmation les plus courants utilisent soit un threading basé sur un verrou, soit une forme d’approche de la simultanéité basée sur un "réacteur". (Je pense que Node.js est le dernier, mais ne m'appelez pas dessus - je n'ai aucun intérêt pour JavaScript dans aucun des aspects de la relation client / serveur.)
• Erlang a une approche de "let it crash" en matière de codage avec de puissantes fonctionnalités d’exécution permettant d’attraper ces pannes, de les diagnostiquer et de les corriger à chaud pendant le fonctionnement du système. Les langages de programmation les plus courants souscrivent à un style de programmation fortement défensif.
• Erlang est presque, mais pas tout à fait, inextricablement associé à une grande bibliothèque d'architectures couramment utilisées pour des serveurs fiables et stables (OTP). (Il y a une raison pour laquelle Erlang est généralement appelé Erlang / OTP.) De plus, cette bibliothèque est construite sur les caractéristiques extraterrestres mentionnées précédemment et est donc opaque pour les nouveaux arrivants. La plupart des langages de programmation ont des bibliothèques moins complètes (avec Java EE), et ces bibliothèques sont, bien entendu, construites sur des concepts mieux connus de la plupart des programmeurs.

Ainsi, apprendre Erlang constituera plus un défi pour la plupart des programmeurs que d'apprendre Node.js, en particulier si le programmeur est déjà familiarisé avec JavaScript. En fin de compte, cependant, une fois passé la barrière conceptuelle, je soumets que le codage Erlang sera moins complexe que le codage équivalent Node.js. C'est pour plusieurs raisons:

• Le modèle de concurrence d'Erlang rend le flux logique beaucoup plus clair que la concurrence typique de type "réacteur" et rend la concurrence beaucoup plus stable et correcte que la concurrence typique basée sur un verrou. Il n’ya presque aucun problème pour un programmeur Erlang à abandonner littéralement des milliers de processus dans un programme typique, tout en insérant des milliers de threads dans, disons, Java serait un cauchemar de différends (pour ne pas mentionner la surcharge de mémoire et de processeur impliquée) l’équivalent de maintenir des milliers d’états distincts dans une configuration basée sur un "réacteur" serait un cauchemar à lire.
• Étant un langage (principalement) fonctionnel, Erlang est vraiment une configuration "ce que vous voyez est ce que vous obtenez". Les variables, une fois définies, ne changent pas. Déjà. Il n'y a pas de "action fantasmagorique à distance" OOP pour vous embrouiller: tout ce avec quoi vous travaillez est explicitement présenté devant vous. Il n'y a pas de variables héritées de X et pas de variables de classe de Y et pas de variables globales de Z pour vous concerner. (Ce dernier point n’est pas vrai à 100%, mais dans un nombre de cas si élevé que c’est suffisant pour la phase d’apprentissage.)
• Grâce aux puissantes fonctionnalités d'erreurs de manipulation d'Erlang, vous encombrez votre code avec une programmation moins défensive, ce qui permet de clarifier la logique et de réduire le code.
• La bibliothèque OTP, une fois que vous y êtes, est une pile incroyablement puissante de code commun qui maintient votre application entière régulière et couvre la plupart des problèmes et des cas d'utilisation de serveurs à longue durée de vie auxquels vous ne penserez probablement pas avant qu'il ne soit trop tard. La bibliothèque OTP elle-même est, IM (ns) HO, une raison suffisante pour apprendre Erlang.

Continuez à suivre Erlang si vous le pouvez, et si vous ne l'avez pas encore fait, rendez-vous sur le site Learn you Some Erlang for Great Good pour une introduction douce et (surtout) amusante aux concepts d'Erlang.

Il existe quelques différences significatives entre Erlang et Node

La première est que le noeud est Javascript, ce qui signifie que c'est un langage très commun qui partage beaucoup de traits avec des langages que plus de gens connaissent, il est donc beaucoup plus facile de se lancer et de fonctionner correctement. Erlang a une syntaxe souvent étrange et peu familière, et bien qu’un langage soit beaucoup plus simple que le javascript, il faut un peu plus de temps pour s’y habituer en raison de son caractère unique.

La seconde est qu’Erlang a un modèle de concurrence très particulier sans partage, il vous oblige à penser différemment pour résoudre les problèmes, ce qui est une bonne chose (TM)

Le dernier point important est qu'Erlang a été développé par une société commerciale et à source ouverte après coup. Il y a seulement 2 ans, les gens pouvaient voir les commits individuels dans le contrôle de code source. Même à présent, je ne pense pas que tous les développeurs erlang ont déménagé. au github public repo pour leur développement. node.js a été construit au sein de la communauté depuis le début. Cela signifie que son support est bien meilleur. Il existe déjà beaucoup plus de bibliothèques pour les noeuds, plus de documentation sur la communauté, plus d'exemples en direct, un gestionnaire de paquets omniprésent, etc. etc. Erlang rattrape son retard. à cet égard, mais il reste encore une rampe beaucoup plus grande pour se lever.

Node vous permettra de programmer des choses amusantes assez rapidement et relativement sans douleur, mais il a encore beaucoup de mal à supporter les applications volumineuses que l’erlang a résolues depuis longtemps. Erlang changera la façon dont vous programmez et (imo) vous fera un meilleur programmeur, mais cela ne vous rendra pas la vie facile au début. Les deux sont amusants de différentes manières.