Apprendre Erlang vs apprendre node.js [fermé]

41

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.

Noli
la source
9
Il me manque peut-être quelque chose, mais node.js n'est-il pas une bibliothèque JavaScript et Erlang un langage complètement différent? Comment sont-ils même comparables?
FrustratedWithFormsDesigner
3
@FrustratedWithFormsDesigner, node.js fait partie d'un récent battage médiatique consistant à obtenir du javascript du côté serveur, avec une approche multi-thread, pour les
rendre
5
@lurscher: Vous ne pouvez pas comparer Erlang (langue) à Node.js (JavaScript côté serveur). Ce serait comme comparer Java (langage) à Django (serveur python). Sans oublier Erlang et JS sont également très différents.
Josh K
10
En tant que personne qui utilise à la fois erlang et node, ils sont définitivement comparables aux problèmes qu'ils résolvent
Dale Harvey
3
@Noli il y a une différence entre node.js et erlang. Vous vouliez faire une comparaison entre les serveurs Web basés sur node.js et erlang. Erlang compte de nombreux utilisateurs en dehors des serveurs Web.
Raynos

Réponses:

46

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.

Je donne des conseils terribles
la source
Pour en savoir plus sur la programmation réactive et le faire dans JS: blog.flowdock.com/2013/01/22/…
Bart
"Parce que vous devez être rappelé pour chaque cas sans conséquence résultant de problèmes de synchronisation et de changements d'état étranges." - à Erlang, vous devez toujours gérer les temporisateurs, et le fait que vous le fassiez "dans les mêmes cas que les réceptions sont effectuées" ne change pas (du tout) la complexité. De mon point de vue (en tant qu’architecte de systèmes traitant des milliards de requêtes par jour), les seules différences réalistes entre la réception sélective et le style node.js sont (a) la question "que voulons-nous faire par défaut" (avec node.js traitement des événements par défaut, et Erlang différant des événements sauf si une correspondance est établie) ...
No-Bugs Hare
... et (b) la lisibilité, y compris la quantité de passe-partout (ce qui est assez mauvais dans node.js classique, mais est devenu beaucoup meilleure - et IMNSHO meilleure que celle d’Erlang - avec un nouvel opérateur d’attente) ... ... Et dans tous les cas , ces différences sont assez esthétiques (malgré les fanatiques des deux côtés qui prêchent autrement).
No-Bugs Hare
38

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.

JUSTE MON AVIS correct
la source
Merci pour ce post. Je suis en train de lire Learn You quelques Erlang maintenant, et je suis à mi-chemin du livre, mais je sens que je devrai tout savoir avant de pouvoir vraiment commencer à faire quelque chose de modéré. important, et pas seulement prendre pièce par pièce
Noli
1
En fait, une fois que vous êtes entré dans les parties concurrentes du livre, vous commencez à être capable de faire assez facilement des choses moyennement importantes.
JUSTE MON AVIS correct le
"Le modèle de concurrence d'Erlang rend le flux logique beaucoup plus clair que la concurrence typique de type" réacteur "" - je dirais que si le traitement asynchrone de réacteur était en effet un désordre pendant des décennies, avec l'avènement des contrats à terme et en particulier des opérateurs cas plus. Avec await, vous pouvez avoir votre coroutines ultra-légers agissant « comme si » ils sont Kinda-fils (et je ne suis pas sûr de JS, mais dans le co_await de C est architecturée à l' échelle de ne pas seulement des milliers, mais à des milliards de circulation coroutines).
No-Bugs Hare
"Il est tout simplement étranger à l'état d'esprit que Chambers Constant (99,44%)" - et pour tout projet industriel, il s'agit d'un gros problème. Ce gros problème persisterait même s’il n’y avait pas de raison objective de l’impopularité des langages fonctionnels (que je n’abrite pas, mais c’est une histoire très différente et longue).
No-Bugs Hare
10

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.

Dale Harvey
la source
2
Il est à noter que les threads de Node ne «partagent rien».
Tamlyn