Erlang Prozesse und Message Passing einfach erklaert

Warum Erlang-Prozesse anders wirken

Ein Erlang-Prozess ist nicht einfach nur ein kleiner Thread. Er ist eine getrennte Arbeitseinheit mit eigener Mailbox und eigener Zustandsgrenze. Ein Prozess kann also nicht heimlich den Zustand eines anderen aendern. Kommunikation wird explizit, weil der normale Weg nur ueber Nachrichten fuehrt.

Das ist einer der Hauptgruende, warum Erlang-Systeme unter Nebenlaeufigkeit so gut nachvollziehbar bleiben. Besitz bleibt lokal, Zusammenarbeit laeuft ueber Protokolle, versteckte Shared-State-Fehler werden seltener.

Was Message Passing dir bringt

Message Passing macht Grenzen sichtbar. Wenn ein Prozess Informationen will, muss er fragen. Wenn er Zustand veraendern moechte, muss er eine definierte Nachricht senden. So entstehen klarere APIs und sauberer Besitz.

Fuer Anfaenger ist das die richtige Denkweise: nicht einfach „viele Dinge gleichzeitig“, sondern „isolierte Akteure arbeiten ueber Nachrichten zusammen“. Wenn diese Idee sitzt, wirkt OTP spaeter viel logischer.

Pid = spawn(fun() -> loop(0) end).
Pid ! increment.
Pid ! {get, self()}.

Wie ein Prozess-Loop funktioniert

Ein zustandsbehafteter Erlang-Prozess ist oft einfach eine rekursive Schleife um receive. Er wartet auf eine Nachricht, reagiert auf genau eine, aktualisiert bei Bedarf seinen lokalen Zustand und ruft sich wieder auf. Die Rekursion haelt den Prozess am Leben und macht den Zustandsuebergang explizit.

Das ist die Bruecke zwischen Rekursion und Nebenlaeufigkeit. Statt an eine while-Schleife ueber ein Objekt zu denken, denkst du an einen Prozess, der nacheinander Nachrichten verarbeitet und in den naechsten Zustand uebergeht.

Wie dieses Thema mit Rekursion und OTP zusammenhaengt

Viele Suchende verstehen Rekursion und wundern sich dann, warum sie bei Prozessen ploetzlich wieder auftaucht. Der Grund ist einfach: ein Prozess-Loop ist nichts anderes als Rekursion, die auf Nachrichten wartet. Die Schleife ist nicht versteckt, sondern explizit.

Genau deshalb fuehrt dieses Thema direkt zu OTP Basics. Sobald du begriffen hast, wie ein Prozess per receive und Rekursion lebt, wird klar, warum GenServer und andere OTP-Behaviors nur standardisierte Versionen dieses Musters sind.

Eine kleine Message-Passing-Walkthrough

Stell dir einen Counter-Prozess vor. Er startet mit 0, bekommt spaeter die Nachricht increment und erhoeht den lokalen Zustand auf 1. Danach sendet ein anderer Prozess {get, self()}. Der Counter antwortet mit {count, 1} und laeuft weiter.

Wenn du diesen Ablauf einmal sauber in Worten beschreiben kannst, sitzt das Kerndenken schon: ein Prozess besitzt den Zustand, Nachrichten beschreiben Aktionen, und Antworten machen das Protokoll sichtbar.

Typische Fehler mit Prozessen

Ein haeufiger Fehler ist, Prozesse wie Objekte mit direktem Feldzugriff zu behandeln. Ein anderer ist, dem Aufrufer in Request-Response-Mustern nicht zu antworten. Ausserdem werden Nachrichten oft zu vage entworfen und ergeben dann kein stabiles Protokoll.

Die beste Korrektur ist, Nachrichtenformen klar zu designen. Nutze Tupel wie {get, From} oder {put, Key, Value}. Lege fest, was jede Nachricht bedeutet, welche Antwort erwartet wird und ob sich der Zustand danach aendert.

Warum diese Seite fuer Suchende wichtig ist

Wer nach erlang message passing oder nach einer deutschen Erklaerung zu Erlang Prozessen sucht, will meist nicht nur wissen, dass Prozesse existieren. Die eigentliche Frage lautet: Warum fuehlt sich Nebenlaeufigkeit hier weniger chaotisch an als in vielen anderen Sprachen?

Genau darauf antwortet diese Seite. Sie verbindet Isolation, Zustandsbesitz, Mailbox-Denken und Prozess-Loops zu einem Bild, das spaeter direkt in OTP uebergeht.

Was du als Naechstes ueben solltest

• Einen kleinen Loop fuer increment schreiben.
• Eine Nachricht {get, From} mit Antwort ergaenzen.
• In einem Satz sagen, welcher Prozess den Zustand besitzt.
• Danach mit OTP Basics weitermachen.

Hauefige Fragen