Grundlagen und Background zur Programmiersprache Elixir – Ein Interview

Hallo Raphael, schön das Du Zeit für uns hast. Lass uns direkt einsteigen: Wo kommt Elixir her? Wer hat es erfunden? Warum?

Das sind ja gleich drei Fragen auf einmal. Ich starte mal mit dem “Warum”.
Elixir ist angetreten, um die Entwicklung von verteilten, hoch verfügbaren und fehlertoleranten Backendsystemen zu vereinfachen. Solche Systeme also, die im Zeitalter der Vernetzung extrem wichtig sind und eine hohe Komplexität aufweisen. Die ersten beiden Fragen werde ich mal zusammen beantworten.

Im Jahr 2011 veröffentlichte José Valim die erste Version von Elixir. Die Sprache ist in vielen Aspekten an Ruby angelehnt. Sie unterscheidet sich aber, um das gleich vorwegzunehmen, auf Laufzeitebene fundamental von Ruby. Die Laufzeit von Elixir, BEAM, ist nämlich auf Nebenläufigkeit, Parallelisierung und damit auf einen hohen Durchsatz optimiert. Die BEAM ist eine virtuelle Maschine, die zusammen, beziehungsweise für die Sprache Erlang entwickelt wurde.

Also ist BEAM und Erlang für Elixir was die JVM und Java für Kotlin oder Scala ist?

Ja, das ist ein sehr guter Vergleich, denn wie Scala mit Java kompatibel ist, ist auch Elixir mit Erlang und dessen Ökosystem kompatibel. Wobei Erlang und dessen Ökosystem ein paar Jahre mehr auf dem Buckel haben als Java.

Was unterscheidet Elixir von anderen?

Für mich persönlich sind da drei Punkte entscheidend, Laufzeit, Syntax und Ökosystem. Alle drei zusammen machen Elixir zu einer extrem interessanten Sprache. Fangen wir mal mit der Laufzeit an. Eins vielleicht noch vorher: Alles, was ich jetzt über Erlang erzähle, gilt natürlich auch für Elixir.

Erlang und die BEAM wurden von/bei Ericsson für den Einsatz in den von Ericsson hergestellten Telefonswitches entwickelt. Und weil diese Anwendungen die gleichen Anforderungen an Software stellen wie vernetzte Anwendungen heute, also verteilt, hoch verfügbar und fehlertolerant, können wir mit der BEAM und Erlang auf einen über 30 Jahre gereiften Lösungsansatz für eben diese Probleme zurückgreifen.

Das klingt alles sehr abstrakt. Kannst du an einen Beispiel konkretisieren wie BEAM und Erlang Anwendungen verteilt, hoch verfügbar und fehlertolerant macht?

Gerne. Die BEAM und Erlang implementieren das Actor Model. Prozesse kommunizieren also ausschließlich über Nachrichten. Jeder Prozess kann Nachrichten an andere Prozesse versenden und hat einen „Posteingang“ für Nachrichten die der Prozess von anderen Prozessen erhalten hat.

Als Java Entwickler kommt mir da gleich Akka in den Sinn, was ja auch das Actor Model Implementiert.

Ja genau. Der Unterschied ist, dass das Actor Model bei Erlang, auf der Sprach- und Laufzeitebene implementiert ist. Es ist somit in der Sprache und nativ in der Laufzeit verankert den es die einzige Möglichkeit der Interprozesskommunikation. Vielleicht sollte ich in dem Zusammenhang auch noch kurz auf den Begriff “Prozess” eingehen.

Ein Prozess bezeichnet in der Erlang Welt einen virtueller Thread, also einen Thread, der von der BEAM und nicht vom Betriebssystem verwaltet wird. Deshalb sind Prozesse in Erlang sehr leichtgewichtig und es ist üblich, tausende davon gleichzeitig auszuführen. Prozesse können darüber hinaus transparent auf verschiedene Nodes in einem Cluster verteilt werden. Ein Prozess, der sich auf einem anderen Node im Cluster befindet, verhält sich also genauso wie ein Prozess, der auf dem gleichen Node ausgeführt wird.

Damit hätten wir geklärt wie Erlang die Entwicklung verteilter Systeme ermöglicht. Was ist mit den anderen beiden Eigenschaften Ausfallsicherheit und Fehlertoleranz?

Die beiden Eigenschaften gehen miteinander einher. Kurz gesagt ist es möglich, dass Prozesse andere Prozesse überwachen und steuern können. Dabei wird die “let it crash” Philosophie umgesetzt. Ein Prozess, der in einen Fehler läuft, “stirbt” einfach, ohne sich viel um Fehlerbehandlung zu kümmern. Der überwachende Prozess kümmert sich um die Fehlerbehandlung, was in den meisten Fällen durch einen Neustart des entsprechenden Prozesses geschieht.

Jetzt haben wir viel über Erlang und die BEAM gelernt. Wo beziehungsweise wie kommt Elixir ins Spiel?

Es mag vielleicht etwas komisch wirken, dass ich so sehr auf Erlang eingehe, aber es ist wichtig zu verstehen, dass durch die Nutzung der BEAM alles, was ich zu Erlang erzählt habe, auch für Elixir gilt. Und jetzt kommen wir zu den Unterschieden. Erlang und Elixir unterscheiden sich hauptsächlich in den Punkten Syntax und Ökosystem.

Die Syntax von Erlang ist, wie gesagt, über 30 Jahre alt, also nicht mehr ganz taufrisch. Elixir hingegen hat eine sehr moderne und meiner Meinung nach gut verständliche Syntax die stark von Ruby inspiriert ist. Das liegt zum einen daran, dass es relativ wenige Sprachelemente gibt und zum anderen an dem massiven Einsatz von Pattern-matching.

Oft gibt es genau einen Weg, ein Problem effizient zu lösen. Es ist sehr einfach, dem Funktionalen Paradigma folgend, komplexe Funktionalität aus einfacher (Teil-) Funktionalität zu “komponieren”. Und wenn dann doch mal ein Sprachelement fehlt, kann man durch Metaprogrammierung, also das Schreiben von Elixir Code durch Elixir Code, eigene Sprachelemente implementieren. Metaprogramming macht die Sprache sehr mächtig und erweiterbar. Beispielsweise lassen sich so domänenspezifische Sprachen erstellen.

Dazu kommt ein solides Ökosystem mit grandioser Dokumentation und einer herzlichen Community. Im Zentrum des Ökosystems steht Mix das Buildtool von Elixir. Es ermöglicht das Scaffolding, Testen und Bauen von Projekten sowie Dependency-Management und vieles mehr.

Wann ist Elixir keine gute Idee?

Das kann man so pauschal nicht sagen, da sich Elixir in meiner Wahrnehmung in letzter Zeit zu einer Allzwecksprache entwickelt. Mit Embedded Elixir lassen sich beispielsweise Microcontroller programmieren und mit Numerical Elixir Berechnungen auf Multidimensionalen Arrays durchführen. Aber der Fokus liegt, wie gesagt, auf verteilten Systemen. Oft wird Elixir mit Phoenix, einem Web-Framework, eingesetzt, um Webanwendungen zu erstellen.

Bis auf einige Ausnahmen kann man sagen, dass Elixir ist nicht für große numerische Berechnungen und systemnahe Anwendungen geeignet ist. Seine Stärken kann Elixir am besten ausspielen, wenn es serverseitig eingesetzt wird.

Was ist Phoenix ?

Phoenix ist ein Framework, beziehungsweise eine Bibliothek, zum erstellen von Web-Anwendungen. Inspiriert wurde Phoenix dabei von Rails, einem ähnlichen Framework für die Programmiersprache Ruby. Wie Rails ist Phoenix in erster Linie auf serverseitiges Rendering nach Model View Controller Musters ausgelegt, mit LiveView wurde vor einiger Zeit ein neues Paradigma eingeführt, dass die Grenzen zwischen Server- und Client-seitigem Rendering in meinen Augen verschwimmen lässt und eine Alternative für single-site-applications sein kann.

Was unterscheidet Phoenix von anderen?

Der größte Unterschied zu anderen bekannten serverseitigen MVC Frameworks ist sicherlich, dass dadurch, dass Elixir eine funktionale Sprache ist und Phoenix ebenfalls mit funktionalen Pattern umgesetzt ist. Das mag an der ein oder anderen Stelle eine Umgewöhnung sein, wenn man aus einem objektorientierten Kontext kommt. Auf der anderen Seite finde ich, dass sich vieles natürlicher anfühlt.

Zum Beispiel?

In Phoenix ist der gesamte Request-Response-Zyklus im Grunde genommen nichts anderes als eine Transformation der Request-Datenstruktur zu einer Response-Datenstruktur mithilfe von Funktionen. Für mich fühlt sich das sehr natürlich an.

Ein weiterer Unterschied ist, dass Phoenix, wie Rails, den Ansatz der Konvention vor Konfiguration verfolgt, deshalb können Projekte schnell an Fahrt aufnehmen, da viel Boilerplate-Code wegfällt.

Was begeistert Dich an Elixir?

Die gesamte Herangehensweise von Elixir ist frisch und einzigartig. Die Laufzeit kann man zum Beispiel als Gegenentwurf zum Microservice-Entwurfsmuster sehen. Denn mit Elixir ist es ohne großen Aufwand möglich, große Anwendungen zu modularisieren und diese Module über ein Cluster zu skalieren und unabhängig voneinander zu deployen. Es lassen sich aber nicht nur sehr große, sondern auch kleine Anwendungen bauen, die mit der Zeit wachsen und skalieren. Die Sprache ist unter Entwicklern beliebt, weil durch den vergleichsweise kleinen Sprachumfang und die gute Dokumentation eine hohe Effizienz erreicht wird.

Bonus – Hast Du einen Quick-Start für mich? Was wäre gute Einstiegsliteratur?

Je nachdem, wie viel Vorerfahrung jemand mit funktionaler Programmierung hat, muss der Einstieg natürlich unterschiedlich tief ausfallen. Insgesamt kann ich aber die Bücher von “Pragmatic Bookshelf”, allen voran “Programming Elixir” empfehlen. Auf der Offiziellen Website gibt es ebenfalls eine gute Einführung in Englischer Sprache.

Raphael, Vielen Dank für Deine Zeit und die Beantwortung der Fragen.