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.
Réponses:
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:
Ensuite, vous avez d'autres événements à prendre en compte, tels que le dépassement de temps pour éviter les blocages:
Ensuite, vous avez également les événements hors limites:
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:
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.
la source
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:
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:
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.
la source
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.
la source