Zuallererst stimme ich der Antwort von JUST MY correct OPINION in Bezug auf das Erlernen von Erlang zu. Es ist eine hauptsächlich funktionale Sprache (obwohl die Nebenläufigkeit eine große Rolle spielt), und alle Funktionen wurden hinzugefügt, um Fehlertoleranz und Robustheit zu gewährleisten, was nicht genau die gleichen Entwurfsziele wie bei Javascript darstellt.
Zweitens ist es etwas verlegt, Node.js zu verlassen, um in Erlang einzusteigen. Node.js ist ein einzelner Server / Framework, mit dem mithilfe von Callbacks alles ereignisgesteuert erledigt werden kann. Erlang hat ein eigenes Framework (OTP), aber es ist überhaupt nicht auf der gleichen Ebene.
Wenn Sie Erlang lernen möchten, empfehle ich meinen Blogeintrag Ein offener Brief an den Erlang-Anfänger (oder Onlooker) als Einführung, bevor Sie in Tutorials eintauchen .
Das einzige, in dem Sie Erlang und Node.js in Bezug auf Muster und Verwendung vergleichen können, ist, wie sie ereignisgesteuert sind. Hier gibt es jedoch zwei große Unterschiede. Das Modell von Node.js basiert auf Rückrufen, die an Ereignisse gebunden sind. Erlang basiert auf Nachrichtenwarteschlangen und empfängt selektiv. Welche Implikationen ergeben sich daraus?
Erstens, wenn Sie Dinge auf Callback-Basis erledigen, ist die einzige Art, wie Sie den Status herumtragen, entweder global zu sein oder in die fortlaufende Stilprogrammierung einzusteigen. Zweitens müssen Sie sich selbst um die vollständige Ereignismatrix kümmern. Ein Beispiel hierfür ist, wenn wir uns eine sehr einfache endliche Zustandsmaschine vorstellen: ein ereignisgesteuertes Mutex-Semaphor.
Das Mutex-Semaphor hat zwei Zustände: gesperrt und frei. Wenn eine bestimmte Recheneinheit (Worker, Prozess, Funktion oder Thread) Zugriff auf den Mutex erhalten möchte, muss sie ein Ereignis auslösen, das besagt, dass ich interessiert bin. Jetzt müssen Sie sich um folgende Arten von Ereignissen kümmern:
- Der Mutex ist kostenlos und Sie fordern die Sperre an
- Der Mutex ist von einer anderen Person gesperrt und Sie möchten die Sperre erhalten
- Der Mutex ist von Ihnen selbst gesperrt und Sie möchten den Mutex freigeben
Dann müssen Sie zusätzliche Ereignisse berücksichtigen, z. B. Zeitüberschreitung, um Deadlocks zu vermeiden:
- Der Mutex wurde gesperrt und Sie haben zu lange darauf gewartet, dass ein Timer zum Aufgeben ausgelöst wird
- Der Mutex wurde gesperrt und Sie haben einfach zu lange gewartet, die Sperre erhalten und dann die Zeitüberschreitung ausgelöst
Dann haben Sie auch die Out-of-Bound-Ereignisse:
- Sie haben gerade den Mutex gesperrt, während ein Arbeiter damit gerechnet hat, dass er frei ist. Jetzt muss die Anfrage des Arbeitnehmers in die Warteschlange gestellt werden, damit sie, wenn sie frei ist, wieder bearbeitet wird
- Sie müssen die gesamte Arbeit asynchron machen
Die Ereignismatrix wird sehr schnell komplex. Unsere FSM hat hier nur 2 Zustände. Im Fall von Erlang (oder einer Sprache mit selektivem Empfang und Asynchronität mit potenziell synchronen Ereignissen) müssen Sie sich um einige Fälle kümmern:
- Der Mutex ist kostenlos und Sie fordern die Sperre an
- Der Mutex ist von einer anderen Person gesperrt und Sie möchten die Sperre erhalten
- Der Mutex ist von Ihnen selbst gesperrt und Sie möchten den Mutex freigeben
Und das ist es. Die Zeitgeber werden in den gleichen Fällen behandelt wie die Empfangsvorgänge, und für alles, was mit "Warten bis es frei ist" zu tun hat, werden die Nachrichten automatisch in eine Warteschlange gestellt: Der Mitarbeiter muss nur auf eine Antwort warten. Das Modell ist in diesen Fällen sehr viel einfacher.
Dies bedeutet, dass in der Regel CPS- und Callback-basierte Modelle wie das in node.js Sie entweder auffordern, sehr geschickt mit Ereignissen umzugehen, oder Sie auffordern, sich vollständig um eine komplexe Ereignismatrix zu kümmern, weil Sie müssen bei jedem unwichtigen Fall zurückgerufen werden, der aus seltsamen Timing-Problemen und Statusänderungen resultiert.
Selektive Empfänge ermöglichen es Ihnen normalerweise, sich nur auf eine Untergruppe aller potenziellen Ereignisse zu konzentrieren, und ermöglichen es Ihnen, Ereignisse in diesem Fall weitaus einfacher zu beurteilen. Beachten Sie, dass Erlang ein Verhalten (Entwurfsmuster / Framework-Implementierung) von etwas hat, das aufgerufen wird gen_event. Mit der Implementierung von gen_event können Sie einen Mechanismus verwenden, der dem in node.js sehr ähnlich ist, wenn Sie dies wünschen.
Es wird andere Punkte geben, die sie unterscheiden; Erlang hat eine präventive Zeitplanung, während node.js kooperativ ist. Erlang eignet sich eher für einige sehr umfangreiche Anwendungen (Distribution und alle), aber Node.js und seine Community sind in der Regel besser mit dem neuesten Webtrend vertraut. Es ist eine Frage der Wahl des besten Werkzeugs, und dies hängt von Ihrem Hintergrund, Ihrer Art von Problem und Ihren Vorlieben ab. In meinem Fall passt das Modell von Erlang einfach sehr gut zu meiner Denkweise. Dies ist nicht unbedingt für alle der Fall.
Hoffe das hilft.