Gleam OTP – Entwicklung fehlertoleranter, aktorbasierten Multicore-Programme

 (github.com/gleam-lang)
1 Punkte von GN⁺ 2025-10-21 | 1 Kommentare | Auf WhatsApp teilen
  • Gleam OTP unterstützt die Entwicklung von Programmen mit Aktor-Modell, Fehlertoleranz und Multicore-Performance
  • Kennzeichnend ist das Ziel vollständiger Typsicherheit und Kompatibilität mit Erlang OTP
  • Bietet Fehlerbehebung und Self-Healing über Supervisoren
  • Stellt nur einen Teil der Funktionen von Erlang/OTP bereit; zusätzliche Verwaltungsstrategien sind derzeit in Entwicklung
  • Unterstützt verschiedene Aktor-Typen wie allgemeine Prozesse, Aktoren und Supervisoren

Überblick über Gleam OTP

  • Gleam OTP ist ein leistungsfähiges Aktor-Framework, das sich an der OTP-Architektur von Erlang orientiert und sich gut für die Implementierung fehlertoleranter Multicore-Programme eignet
  • Es ist ein Open-Source-Projekt unter der Apache-2.0-Lizenz

Zentrale Merkmale und Vorteile

  • Gewährleistet vollständige Typsicherheit für Aktoren und Nachrichten
  • Bietet Kompatibilität mit Erlang OTP, was die Integration in bestehende Erlang-Umgebungen erleichtert
  • Unterstützt Fehlertoleranz durch Supervisoren (supervisor) mit Fehlererkennung, automatischer Wiederherstellung und Shutdown-Management
  • Zielt auf dieselbe Performance wie Erlang OTP ab
  • Dokumentation und Beispiele erleichtern den produktiven Einsatz und das Lernen

Erläuterung der Aktor-Typen

  • Prozess (process)

    • Der grundlegendste Baustein innerhalb von OTP
    • Dient als Basis für andere Aktor-Typen, wird in Gleam-Anwendungen aber selten direkt verwendet

  • Aktor (actor)

    • Der am häufigsten genutzte Prozesstyp, mit einer ähnlichen Funktion wie Erlangs gen_server
    • Verarbeitet OTP-Systemnachrichten automatisch und aktiviert Debugging- und Tracing-Funktionen

  • Supervisor (supervisor)

    • Startet andere Prozesse und ist für Überwachung und Wiederherstellung zuständig
    • Startet Kindprozesse bei Abstürzen oder Ausnahmen automatisch neu
    • Bildet über verschachtelte Supervisoren (supervision tree) die fehlertolerante Struktur einer Anwendung
    • Details zur Implementierung finden sich in der Dokumentation zu gleam/otp/static_supervisor und gleam/otp/factory_supervisor

Einschränkungen und Probleme

  • Derzeit unterstützen Aktoren nicht alle OTP-Systemnachrichten; nicht unterstützte Nachrichten werden ignoriert
  • Einige Funktionen der OTP-Debugging-API sind eingeschränkt
  • Falls nötig, kann über ein Issue Unterstützung für noch nicht implementierte Nachrichten angefragt werden

Fazit und Bedeutung des Projekts

  • Gleam OTP erweitert die Stärken des Erlang-Ökosystems auf die Sprache Gleam und ist besonders bedeutsam, weil es Typsicherheit und fehlertolerante Multicore-Fähigkeit ermöglicht
  • Eignet sich für Anwendungen, bei denen Stabilität und Performance im produktiven Einsatz wichtig sind
  • Ein Open-Source-Projekt mit hohem Lern- und Praxiswert für Startups, IT-Fachentwickler und Entwickler allgemein

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-10-21
Hacker-News-Kommentare
  • Ich habe ein kleines Projekt mit gleam/lustre begonnen und bin bisher wirklich sehr zufrieden.
    Wenn du dich für statische Typen, eine nullfreie Umgebung, funktionale Programmierung und Sprachen aus der ML-Familie interessierst, kann ich empfehlen, gleam auszuprobieren.
    Und natürlich läuft es auf der BEAM.
    • Sehe ich genauso.
      Als ich gleam installiert habe, wurden auf meinem System ungefähr 50 Pakete installiert; das sind vermutlich Pakete rund um Erlang/Elixir.
      Ich frage mich, wie es wäre, wenn man nur nach JS transpiliert. Vielleicht ist das auch einfach ein Packaging-Problem auf meinem System.
      Noch besser fände ich Unterstützung für Lua als Transpilation-Target. Meiner Meinung nach ist Lua beim Einbetten einer DSL in andere Programme mindestens dreimal einfacher als eine JS-Runtime.
      Am besten war bisher vor allem die Community. Die Qualität der Bibliotheken und Materialien in der gleam-Community ist außergewöhnlich hoch.
      Das erinnert mich an die Rust-Community: Schwierige Probleme wurden bereits von klugen Leuten angegangen, und gute Lösungen tauchen schnell auf (lustre, squirrel usw.).
      Auffällig ist auch, wie viel Experimentierfreude und kreative Ansätze es gibt. Dinge, die man in großen Sprach-Ökosystemen kaum noch sieht, stechen hier hervor. Und während die Community wächst, bleibt die Atmosphäre sehr einladend.
    • An all den Dingen, die du genannt hast, bin ich interessiert. Aber ich verstehe BEAM oder OTP noch nicht wirklich.
      Hast du eine Empfehlung, wo man am besten mit dem Lernen anfängt?
    • Aus Sicht von jemandem ohne Erfahrung mit den zuvor genannten Dingen frage ich mich, ob man zuerst gleam/lustre oder elixir/phoenix lernen sollte.
  • Ich frage mich, ob Leute, die Gleam verwenden, auch ein Web-Framework wie Phoenix einsetzen.
    Ich schaue mich gerade um, weil es wirklich großartig wäre, wenn man ein Framework wie Phoenix zusammen mit Gleam verwenden könnte.
    Im Moment plane ich ein neues Projekt in Python, aber wenn es mit Gleam eine brauchbare Option gibt, würde ich das gern ausprobieren.
    • Es gibt einen Vortrag des Lustre-Entwicklers, in dem mit Gleam/Lustre eine Funktion ähnlich zu LiveView umgesetzt wird.
      Ein Vorteil ist, dass man sehr einfach entscheiden kann, welche Teile ins Frontend bzw. Backend gehören.
      YouTube-Link
    • Ein vollständiges Framework wie Phoenix, Django oder Rails gibt es noch nicht.
      Stattdessen gibt es Werkzeuge, die man beim Bau von Web-Apps häufig verwendet.
      Lustre ist ein grundlegendes View-Tool, und Wisp übernimmt die Server-Rolle.
      Für SQL gibt es squirrel und POG (neu, aber beliebt).
  • PureScript ist eine ausgereifte funktionale Programmiersprache mit Unterstützung für ein Erlang-Backend.
    Wenn man auf der BEAM eine andere statisch typisierte Alternative braucht, ist das eine gute Wahl.
    Es ist gewissermaßen ein Haskell-Dialekt und unterstützt strikte Auswertung sowie Row-Polymorphismus.
    • Das JS-Backend von PureScript ist ausgereift, aber das Erlang-Backend und dessen Ökosystem sind im Vergleich zu Gleam sehr klein.
    • Auf der offiziellen Website und im GitHub-Repo steht nur, dass PureScript nach JS kompiliert wird; mich würde interessieren, woher du von dem Erlang-Backend erfahren hast.
  • Ich interessiere mich sehr für Erlang/BEAM, hatte aber nie die Zeit, es tatsächlich auszuprobieren.
    Mich würde interessieren, wie es in der Praxis eingesetzt wird. Baut man damit die komplette Service-Logik auf, oder nutzt man es nur für bestimmte Teile?
    • Ich leite ein Team und wir führen gerade eine schrittweise Migration zu Gleam durch.
      Wir haben das Muster „functional core, imperative shell“ bis zum Äußersten getrieben und Gleam so ausgekoppelt, dass es die rechenintensiven Aufgaben in einer bestehenden Ruby-on-Rails-Codebasis übernimmt.
      OTP-Funktionen verwenden wir fast gar nicht, und Rails konzentriert sich nur auf seine eigentlichen Stärken wie Web-UI und HTTP-API.
      Rails übernimmt das Aufsetzen der Eingabewerte für Jobs, und die Job-Daten werden über Redis als ein einziger atomarer Wertesatz an Gleam übergeben.
      Mit Elixir haben wir einen dünnen Wrapper gebaut, der nur Netzwerk- und Datei-I/O erledigt, während die Business-Logik in Gleam-Modulen liegt.
      Ich plane, diesen Ansatz bald technisch ausführlicher in einem Artikel zu beschreiben. Das ist auf HN oft ein Thema, das auf Interesse stößt.
    • Wir machen bei TV Labs mit Elixir ganz unterschiedliche Dinge: Web-Services, eine Echtzeit-Matching-Engine, Lua-Code-Sandboxing, Kommunikation mit Mikrocontrollern über ein Binärprotokoll, Machine Learning und mehr.
      Elixir ist eine hervorragende Sprache für allgemeine Zwecke und hat in vielen Bereichen Stärken.
      Für ein ausführlicheres Gespräch siehe mein Developer-Voices-Video.
      YouTube-Link
    • Ich würde empfehlen, zu elixirforum.com zu kommen und dort mitzudiskutieren.
      Viele Leute bauen ernsthafte Systeme ausschließlich mit Erlang/Elixir & BEAM, also kannst du dort Fragen stellen und bekommst wahrscheinlich gute Antworten.
    • Ich habe beide Herangehensweisen gesehen.
      Wenn man OTP einmal gut verstanden hat, fühlt es sich natürlich an, komplette Systeme darauf aufzubauen.
      Ich selbst habe das sieben Jahre lang so gemacht, habe aber auch erlebt, dass neue Entwickler lange brauchen, um sich in dieses Ökosystem einzuarbeiten.
  • Meiner Meinung nach würde Gleam ernster genommen werden, wenn auf der Projektseite keine starken politischen Botschaften stünden.
    Ich sehe keinen Grund, auf der Seite eines technischen Projekts unbedingt über Politik zu sprechen.
    Es geht mir nicht darum, ob man zustimmt oder nicht; ich denke nur, dass man solche Diskussionen in einem professionellen Kontext besser weglässt.
    Sonst driftet das Gespräch unnötig vom Thema ab.
    • Du meinst die eine Zeile unten auf der Seite: „Black lives matter. Trans rights are human rights. No nazi bullsh*t.“?
      Wenn du es wegen dieses einen Satzes nicht verwenden willst, dann würde ich sagen, dass es genau wie beabsichtigt funktioniert.
    • Du sagst, „das Gespräch driftet unnötig vom Thema ab“,
      aber ich denke eher, dass du selbst genau das getan hast.
  • Für mich wirkt es so, als verursache das Actor-Modell Probleme des verteilten Rechnens, sobald Informationen zwischen Prozessen geteilt werden müssen.
    Für Fehlertoleranz und Multicore halte ich Software Transactional Memory und funktionale Effekt-Systeme wie bei Scala/ZIO für die bessere Wahl.
    Das Actor-Modell kann man natürlich weiterhin verwenden, wenn es gebraucht wird.
    Außerdem sind Reifegrad des JVM-Ökosystems, Observability und Praxistauglichkeit der BEAM überlegen.
    • Das ist aus meiner Sicht eine ziemlich ungewöhnliche Perspektive.
      Ich kann verstehen, die Schwächen der BEAM zu kritisieren, aber ihre Stärken zu kritisieren, fühlt sich seltsam an.
      Die BEAM basiert darauf, unveränderliche Nachrichten zwischen leichtgewichtigen und günstigen Green Threads auszutauschen.
      Mit robusten Supervisor Trees muss man sich weder um Data Races noch um blockierende Threads sorgen.
      All das ist fest eingebaut, sodass es kaum Boilerplate gibt.
      Dank Immutability ist die Performance auch überraschend gut.
      Am Ende ist die BEAM eine Plattform, die besonders stark auf fehlertolerante, verteilte und nebenläufige Systeme optimiert ist.
    • Ein Punkt, der noch nicht erwähnt wurde: Erlang (die Grundlage von gleam) ist eine Sprache, mit der 99.9999999 % Uptime erreicht wurden.
      Ein großer Teil dieser Robustheit kommt von widerstandsfähigem Supervising und Infrastruktur über Maschinen hinweg.
      Es ist eine Sprache, die die Entstehung von Actor-Systemen stark inspiriert hat.
      Erlang existiert im Grunde genau für diese eine Aufgabe, und darin ist es wirklich sehr gut.
    • Du hast gesagt, „das Actor-Modell hat Schwierigkeiten mit gemeinsam genutzten Daten“, aber tatsächlich funktioniert es so, dass Daten kopiert oder per Message Passing mitsamt Besitz übertragen werden.
      Wenn Daten wirklich gemeinsam genutzt werden müssen, dann müssen sie in jedem Fall unveränderlich sein.
    • Kannst du ein Beispiel für eine Situation nennen, in der man mutable Daten nicht als immutable Datenstruktur übergeben kann?
      Mir fällt da eigentlich nur extrem harte numerische Berechnung ein, aber so etwas würde man ohnehin nicht direkt in elixir oder erlang schreiben, sondern als NIF implementieren.
    • In Elixir/Gleam/OTP besteht ein Programm vollständig aus einer Menge unabhängiger Prozesse.
      Auch wenn man das Actor-Pattern nicht explizit verwendet, sind Zustandsübergabe und Koordination dort bereits gelöste Probleme.
      Es gibt alle grundlegenden Primitive wie Tasks, Agents, GenServer und Supervisoren.