Neue Wege

Anfänglich beschäftigt man sich mit Elixir meist wegen der hohen Geschwindigkeit, der einfachen Skalierbarkeit und der möglichen Parallelverarbeitung, die sich nicht nur über alle CPUs eines Servers, sondern auch über alle Nodes eines Clusters erstrecken kann.

Wesentlich für die Skalierbarkeit und Parallelität sind die Immutability (Unveränderlichkeit) und der eingeschränkte Scope von Variablen. Eine Variable zeigt auf eine Adresse im Speicher, die der Anwender in vielen Programmiersprachen einfach überschreiben kann. Das führt dann teilweise zu ungewollten Effekten, etwa weil ein bestimmter Teil des Programms einen Wert geändert hat und ein anderer Teil des Programms das nicht weiß oder berücksichtigt. Das wirkt sich besonders kritisch aus, wenn mehrere CPUs oder Nodes parallel am gleichen Problem arbeiten.

Nicht so in Elixir: Hier bekommt der neue Wert im Moment der Zuweisung eine neue Adresse im Speicher. Funktionen, die vor der Veränderung des Werts mit dieser Variable gearbeitet haben, greifen weiter auf die alte Adresse zu, neue Funktionen nutzen die neue Adresse. Sobald sich eine Funktion beendet, löscht die Garbage Collection alle mit ihr verbundenen Werte.

Und das soll schnell sein? Ja, denn es verursacht weitaus mehr Aufwand, existierende Speicherinhalte durch neue Werte zu ersetzen, als einen neuen Bereich im Speicher mit dem neuen Wert zu füllen und beim Beenden der Funktion einfach alle Verweise per Garbage Collection zu löschen.

Aus diesem Grund kann man ein Elixir-System auch per Hot Deployment im laufenden Betrieb aktualisieren, ohne bestehende Verbindungen oder Prozesse beenden zu müssen. Ebenso wenig muss eine Armada an parallelen Servern oder Diensten für die kurze Zeit des