Das Wesentliche an Erlang ist nicht die Leichtgewichtigkeit seiner Prozesse und die Nachrichtenübermittlung (2023)

Hintergrund

• Erlang ist eine Sprache, die für den Aufbau zuverlässiger verteilter Systeme entwickelt wurde; sie begann zunächst als Prolog-Bibliothek und entwickelte sich zu einer eigenständigen Sprache.
• Sie wurde bei Ericsson zur Programmierung von Telefonvermittlungsanlagen verwendet und wurde 1998 als Open Source veröffentlicht.
• Joe Armstrong war einer der wichtigsten Designer von Erlang; seine Dissertation behandelt, wie man trotz Softwarefehlern zuverlässige verteilte Systeme erstellt.

Behaviours

• Behaviours in Erlang ähneln Interfaces in Java oder Go und sind Sammlungen von Typsignaturen, die mehrere Implementierungen haben können.
• Bei Behaviours muss man nur den Code schreiben, der die Business-Logik des Programms definiert; der Infrastruktur-Code wird automatisch bereitgestellt.
• Behaviours werden von Experten geschrieben und basieren auf Best Practices.

Allgemeines Server-Behaviour

• gen_server wird anhand eines Beispiels zur Implementierung eines Key-Value-Stores erläutert.
• handle_call ist dafür zuständig, den Zustand zu aktualisieren oder einen Schlüssel abzufragen; die gesamte Nebenläufigkeit ist in der gen_server-Komponente verborgen.

Event-Manager-Behaviour

• gen_event ist ein Event-Manager, der Event-Handler registriert und ausführt, wenn Nachrichten eintreffen.
• Es ist nützlich für Fehlerprotokollierung; ein einfaches Logger-Beispiel wird gezeigt.

Zustandsmaschinen-Behaviour

• gen_fsm wurde in gen_statem umbenannt und eignet sich gut zur Implementierung von Protokollen.

Supervisor-Behaviour

• Ein Supervisor stellt sicher, dass andere Prozesse ordnungsgemäß funktionieren, und startet sie bei Fehlern gemäß einer vordefinierten Strategie neu.
• Die Strategie one_for_one startet nur den fehlgeschlagenen Prozess neu, während bei one_for_all beim Ausfall eines Prozesses alle Kinder neu gestartet werden.

Application- und Release-Behaviour

• Eine Application enthält einen Supervisor-Baum und alles Notwendige; ein Release paketiert eine oder mehrere Applications.
• Bei fehlgeschlagenen Upgrades sollte ein Rollback möglich sein.

Implementierung von Behaviours

• Mehr noch als Erlangs leichtgewichtige Prozesse und Nachrichtenübermittlung führt die Struktur der Behaviours zu zuverlässiger Software.
• Um Behaviours in anderen Sprachen zu implementieren, kann man mit Interface-Signaturen beginnen.

Korrektheit von Behaviours

• Simulationstests erleichtern das Testen verteilter Systeme, und mithilfe der Struktur des gen_server-Behaviours lässt sich die Problemlösung vereinfachen.

Beitrag

• Es gibt Ideen wie das Übernehmen von Ideen aus der Arbeit von Martin Thompson, um einen schnellen Event-Loop zu bauen und asynchrones I/O hinzuzufügen.
• Bei Interesse oder für Meinungen, Vorschläge und Fragen kann man Kontakt aufnehmen.

[GN⁺]

Hacker-News-Kommentar

• Das Erstaunliche an Erlang und BEAM ist die Tiefe ihrer Funktionen. Für den OP war Erlangs Behavior/Interface der größte Gewinn. Ich persönlich halte es für wichtig, dass man mit deutlich weniger Entwicklungsressourcen als in anderen Sprachen komplexe Systeme bauen kann. Für viele Menschen sind die leichtgewichtigen Prozesse und das Programmiermodell attraktiv

  • OTP enthält enorm viele Funktionen. Wir arbeiten daran, Elixir so zu kompilieren, dass es auf iOS-Geräten laufen kann. Mit Erlangs ei-Bibliothek kann man in C Nodes kompilieren und mit anderen Erlang-Nodes interagieren. Über Erlangs rpc-Bibliothek sind Funktionsaufrufe aus C und die Anbindung an Elixir-Anwendungen möglich
  • Erlang hat viele Probleme gelöst, mit denen moderne Tech-Stacks noch kämpfen, und Fragen der Skalierbarkeit und der Implementierungskosten schon vor Jahrzehnten bewältigt. Auf HN hat das Interesse an Erlang/Elixir jedoch nicht zu tatsächlicher Adoption geführt, und viele Firmen verschwenden Geld damit, Dinge nachzubauen, die der Erlang-Stack kostenlos mitliefert

• Ich habe mit Leuten zusammengearbeitet, die gemeinsam mit einigen Managern auf Basis ihrer Erfahrungen ein Buch schreiben wollten. Wir waren uns immer uneinig darüber, worauf der Erfolg zurückzuführen ist. Manche behaupten, leichtgewichtige Prozesse und Message Passing seien nicht die geheime Zutat, übersehen dabei aber, dass Erlangs Communicating Sequential Processes von diesen Eigenschaften nicht zu trennen sind

  • Beispiel: Anwendungsprogrammierer schreiben sequentiellen Code, und die gesamte Nebenläufigkeit ist in den Behaviors verborgen
  • Für neue Teammitglieder ist der Einstieg leicht: Die Business-Logik ist sequentiell und ähnelt Strukturen, die sie vielleicht schon einmal gesehen haben
  • Supervisoren und die Philosophie „let it crash“ tragen dazu bei, zuverlässige Systeme zu bauen

• Wegen der leichtgewichtigen Prozesse und des Message Passing habe ich mich wieder für Erlang interessiert. Bis jetzt waren Behaviors eher zweitrangig

  • Das Projekt bringt visuelles Flow-Based Programming (FBP) nach Erlang. FBP scheint gut zu Erlang zu passen, und ich war überrascht, dass es das bereits gibt
  • Wir verwenden Node-RED als Werkzeug für FBP, und die Grundidee ist, das Node-RED-Frontend mit einem Erlang-Backend zu verbinden und alle Nodes zu Prozessen zu machen

• Ich habe nach Informationen gesucht, warum Ericsson Erlang nicht mehr verwendet und was es mit Joes Entlassung auf sich hatte

  • Die kurze Antwort ist, dass Erlang an den Rand gedrängt wurde, als man für neue Projekte auf Java umstieg. Joe und seine Kollegen gründeten 1998 Bluetail, das von Nortel übernommen wurde. Nortel war ein Telekommunikationsriese, dessen Aktie im Jahr 2000 $125 erreichte, 2002 aber unter $1 fiel. Das hing mit dem Platzen der Dotcom-Blase und sinkenden Telekom-Ausgaben zusammen

• Die Stärke von Erlang/Elixir liegt nicht in der Implementierung des Actor-Modells, nicht in Prologs Matching, nicht in Immutability oder Behaviors, sondern in Joes Drang zu zeigen, dass man mit wenigen Ressourcen mehr erreichen kann

  • Es ist ein gut entworfenes, kohärentes System und besitzt eine Konsistenz, die man in anderen Sprachen nur selten sieht. Es ist nicht perfekt, aber beeindruckend
  • Ich denke, in der Softwarewelt fehlt oft das Bewusstsein für die Kraft der Einfachheit und die Bereitschaft, sie anzunehmen

• Erlang, OTP und BEAM bieten mehr als nur Behaviors. Die VM ähnelt einem virtuellen Kernel und bietet Supervisoren, isolierte Prozesse und einen verteilten Modus. OTP liefert nützliche Module wie Mnesia (Datenbank), atomare Counter/ETS-Tabellen (Caching) und mehr

  • Vor einem Jahr habe ich in meiner kleinen Beratungsfirma Erlang als Backend-Sprache eingeführt. Ich habe die Interna von BEAM untersucht, um den TCP-basierten Stack durch QUIC zu ersetzen und Rust-Patches zu integrieren

• Das interessanteste Konzept in Erlang/BEAM ist, dass partielle Wiederherstellung grundsätzlich eingebaut ist. Wenn ein unerwarteter Zustand auftritt, wird nicht der gesamte Prozess beendet oder das Risiko einer Beschädigung in Kauf genommen, sondern auf der kleinstmöglichen Ebene in einen bekannten guten Zustand zurückgesetzt

• Der Grund, warum andere Sprachen und Bibliotheksdesigner Erlangs Behavior-Struktur nicht einfach übernehmen, ist, dass die Signaturen der Behavior-Funktionen eng mit anderen Eigenschaften von Erlang verbunden sind, insbesondere mit dessen spezieller Nutzung von Immutability

  • Um in anderen Sprachen dasselbe Ziel zu erreichen, sollte man Erlangs Ansatz nicht direkt kopieren. Von Erlangs zuverlässiger Software zu lernen ist empfehlenswert, aber ich würde stark davon abraten, Erlangs Vorgehensweise 1:1 in andere Sprachen zu portieren

• Ich stimme dem Inhalt dieses Artikels nicht zu. Behaviors sind dank der grundlegenden Architektur des Systems möglich. Behaviors sind kein Interface, sondern eher abstrakten Objekten in Sprachen wie Java ähnlich

  • Joes Arbeit zeigt, wie man mit einem gegebenen Satz Lego-Steine zuverlässige Systeme baut

• Behaviors sind nicht besonders interessant. Sie gibt es auch in anderen Programmiersprachen. Das Interessante an BEAM ist, dass das Werfen von Fehlern sehr elegant ist. Das Werfen von Fehlern und die Stärke von Behaviors machen es einfach, Fehler abzufangen, Kontextinformationen zu melden und das Ganze allgemein gut komponierbar zu halten