Software ohne Grenzen: Das war wohl das Ziel der kleinen Entwicklertruppe von Whatsapp, die sich bei der Auswahl der Kerntechnologie ihres Messengers 2009 für Erlang entschied. Mehr als neun Millionen Nachrichten pro Sekunde und über 450 ­Millionen aktive Clients: Das sind ­Größenordnungen, bei denen sich die nach dem dänischen Mathematiker Agner Krarup ­Erlang benannte Programmiersprache zu Hause fühlt. Whatsapps Mutterkonzern Facebook setzt bei einem Teil des Facebook-Chat-­Backends ebenfalls auf Erlang. Und auch Amazon hat sich innerhalb der Amazon Cloud bei der Entwicklung der SimpleDB für die Sprache entschieden.

Ein Blick auf diese prominenten Beispiele zeigt: Die schon 1987 erschienene Programmiersprache ist alles andere als ein Fall für die Mottenkiste. Im Gegenteil: Die steigende Verbreitung und wachsende Community von Erlang sprechen derzeit für eine Renaissance des Programmierurgesteins. Waren die Anwendungsfälle in der Vergangenheit eher infrastrukturell ­getrieben, findet Erlang heute sogar immer mehr den Weg ­Richtung ­Endanwender. Dazu verhelfen dem Ökosystem insbesondere die moderne und attraktive Programmiersprache Elixir sowie das damit realisierte Webframework Phoenix. Was macht Erlang so besonders?

Ähnlich wie Java ist Erlang nicht nur eine Programmier­sprache. Hinter dem Begriff stehen auch eine Laufzeitumgebung, die ­Erlang VM, sowie ein Ökosystem an Tools und Bibliotheken. Die Basis der Sprache und ihres Ökosystems ist auf ­parallele Verarbeitung ausgerichtet. Diese Tatsache hat seit 25 Jahren ­Bestand und seitdem beweist Erlang eine Stabilität, die ihres­gleichen sucht. Ein gutes Beispiel hierfür ist der AXD-301-Switch, welcher mit Erlang programmiert ist und dabei eine Verfügbarkeit von 99,9999999 Prozent verzeichnet. Die Fähigkeit, ­Millionen von Nachrichten parallel stabil und effizient abzuarbeiten, ist kein Zufall, sondern basiert auf Erlangs internen Konzepten.

In einem Erlang-System wird jede Aufgabe von sparsamen, autarken User-Space-Prozessen abgearbeitet. Diese Prozesse kommunizieren über Nachrichten miteinander und besitzen einen entsprechenden Posteingang. Diese Idee passt nicht nur ­perfekt zu einer Nachrichtenanwendung wie Whatsapp, sondern zu jedem Anwendungsfall, bei dem nebenläufige und unabhängige Prozesse eine Rolle spielen. Das trifft auf IoT-Systeme mit ihren individuellen Sensoren und Steuereinheiten genauso zu wie auf skalierbare Webanwendungen. Jeder Nutzer agiert im Web als eigenständiger Prozess mit seinem eigenen Speicherbereich wie beispielsweise einem Warenkorb.

Im Vergleich zu anderen Ökosystemen wie Java, welches mit Threads arbeitet, haben Erlangs Prozesse keinen shared ­State, also keinen geteilten Speicherbereich. Das führt zu wesentlich mehr Stabilität und verhindert ungewollte Seiteneffekte. Außerdem ist der Footprint eines solchen Prozesses extrem gering, sodass man selbst auf einem leistungsschwächeren Microcomputer tausende von Prozessen parallel starten kann – und das ohne Speicherprobleme zu erzeugen. Für diese Anwendungsfälle braucht man in Erlang kein Experten­wissen und muss auch nicht handverlesen die richtige Wahl für das korrekte Framework treffen. Man kann in dieser Hinsicht keine grundsätzlichen Fehler machen.

Ein weiterer Punkt, der den Entwicklern von Whatsapp wohl ebenfalls sehr wichtig war, ist der geringe Ressourcenverbrauch von Erlang. Gängige ­Webserver inklusive deren Software und Frameworks verbrauchen ­gerne mehrere hundert Megabyte Arbeitsspeicher, Java-Entwickler sind auch schon mal im Gigabyte-Bereich ­unterwegs. Mit einer Webanwendung auf der Erlang VM inklusive Tools und einem Webserver bleibt man oftmals sogar unter 20 Megabyte Arbeitsspeicherverbrauch. Dieser große Dimensionsunterschied wird schnell mit einem Lächeln abgetan: Arbeits­speicher koste doch heutzutage nichts mehr. Dem kann man teilweise zustimmen. Der entscheidende Faktor an dieser Stelle ist aber die Entwicklungsgeschwindigkeit. Das Starten eines Erlang-Webservers ­inklusive Anwendung und VM dauert in der Entwicklung in der Regel zwei bis vier Sekunden. Entwickeln ohne Wartezeit ist nicht nur kostentechnisch effizienter, sondern macht auch den Entwicklern mehr Spaß.

Auch die Skalierbarkeit von in Erlang geschriebenen Anwendungen spricht für sich. Das zeigt sich am Beispiel eines MVP (Minimum Viable Product), mit dem viele erfolgreiche IT-Systeme starten: Ein kleiner Prototyp, der beweisen soll, dass die Ideen sinnvoll und realistisch sind. Software-Ingenieure haben dabei in der Regel die Aufgabe, in kurzer Zeit mit wenig Overhead und Kosten ein stabiles und vor allem erweiterbares System zu schaffen. Erweiterbarkeit hinsichtlich der nichtfunktionalen Anforderungen stellt sie dabei vor besonders große Herausforderungen. Diese sind es nämlich, die der Technologie und deren Architektur alles abverlangen. Wie schafft man es beispielsweise, dass ein kleines Stück Software später von Millionen Nutzern parallel genutzt werden kann? Der Scale-Out von Klein nach Groß wird MVP oft zum Verhängnis und sorgt dann in der Praxis dafür, dass eine komplette Neuentwicklung ansteht. Mit Erlang passiert das in der Regel nicht, denn hier ist für eine unbegrenzte Anzahl an parallel arbeiteten Clients bereits vorgesorgt. Falls der Prototyp erfolgreich wird und ein Scale-Out ansteht, sind die Entwickler sogar in der Lage, die Software horizontal auf verschiedene Server zu installieren und parallel zu betreiben.

Ein weiterer Vorteil von Erlang versteckt sich hinter dem zunächst bizarr wirkenden Appell „Let it Crash“. Dahinter steht die Erkenntnis, dass Software-Ingenieure niemals in der Lage sind, ein hundertprozentig stabiles System zu kreieren – welches sich in jeder undenkbaren Situation fehlerfrei verhält. Während andere Technologien ihren Quellcode durch Try-Catch-Blöcke punktuell abzusichern versuchen und somit enthaltene Fachlichkeit verwässern, sind Erlang-Entwickler davon überzeugt, dass das kontraproduktiv ist. Besser sei es, in einem Fehlerfall den Prozess crashen zu lassen. Dies gilt aber nur dann, wenn man darauf vorbereitet ist und für Fehlerfälle vorgesorgt hat. Glücklicherweise wird einem dazu das sogenannte Supervisor Behaviour an die Hand gegeben. Ein Prozess, welcher als Supervisor implementiert wird, verwaltet seine ihm zugeordneten Child-Prozesse. Er kontrolliert, startet, stoppt und räumt in Fehlersituationen wieder auf. Dies ist keine blanke Theorie, sondern gelebte Praxis, da es diverse auf Erlang basierende produktive Systeme gibt, die in puncto Ausfallsicherheit ihresgleichen suchen.

Für Erlang gibt es zu den meisten gängigen Persistenztechnologien die entsprechenden Treiber. Man kann also wie gewohnt flexibel je nach Anwendungsfall zwischen den NoSQL Datenbanken auswählen. Hier sollte man als Einsteiger aber nicht allzu schnell auf altbekannte Wege zurückgreifen, denn Erlang hat darüber hinaus auch eigene Datenbanksysteme in petto. Beispielsweise Mnesia, das aufgrund seiner Performance, seines Speicherverbrauchs und Reifegrads unbedingt in Betracht gezogen werden sollte.

Um- oder Einsteiger werden schnell mit dem speziellen ­Charakter konfrontiert, der Erlang innewohnt. Andere Platt­formen beispielsweise tendieren überwiegend dazu, Standards wie HTTP durch Frameworks zu abstrahieren und zu kapseln. Als ­Erlang-Entwickler wird man dagegen dazu bewogen, sich mit den Basistechnologien auseinanderzusetzen. Das fühlt sich zunächst grober und rauer an, denn man findet sich eher beim Durch­blättern einer RFC (Request For Comment)-Spezifikation wieder, als beim Konsumieren eines hübschen Framework-­Tutorials.

Das Resultat dieser Vorgehensweise ist jedoch ein tiefes Verständnis der Technologien, die man im Entwicklungsalltag verwendet. An dieser Stelle könnte man als Entwickler befürchten, dass man dazu gezwungen wird, tonnenweise Quellcode zu ­produzieren und dass die Entwicklung und das Refaktorisieren an sich sehr aufwendig werden. Genau das Gegenteil ist aber der Fall. Die Erlang-Sprache selbst ist sehr sparsam und gibt einem das OTP-Toolset an die Hand, welches Lösungen und Muster, sogenannte Behaviours, für die gängigsten Problemstellungen ­liefert.

Vielleicht liegt es an dieser von manchem Anwender sicherlich empfundenen Sperrigkeit, dass Erlang bis heute in Deutschland keinen hohen Bekanntheitsgrad besitzt. Während sich die Verbreitung in Grenzen hielt, hat sich Erlang über die Jahre immer wieder als eine stabile und „battle-proven“ Alternative bewiesen. Multicore-CPU-Architekturen, Ausfallsicherheit, Parallelität im Web: Diese topaktuellen Themen werden von Erlang besser adressiert als von den meisten anderen Plattformen. Das einzige also, das einem an Erlang altbacken vorkommen könnte, wäre die Programmiersprache an sich – die auf den ersten Blick nicht wirklich zugänglich aussieht.

Das liegt nicht nur an der Lexikalik und der Syntax, sondern auch an den Besonderheiten von funktionalen Programmiersprachen. In Erlang wird der Code grundlegend anders strukturiert, als viele Entwickler es aus objektorientierten oder prozeduralen Sprachen kennen. Beispielsweise werden anstelle von Schleifen Tail-Recursions verwendet oder mit Pattern Matching Nachrichten den Funktionen zugewiesen oder Datengruppen definiert. Die Tail-Recursion wird in funktionalen Sprachen oft als Ersatz von Iterationen verwendet. Im Gegensatz zu einer naiven Rekursion steigt der Speicherplatzverbrauch nicht mit jeder weiteren Rekursion und ist somit sowohl funktional integer als auch effizient. Das Pattern Matching bedient sich der Symbolik und Struktur von Argumenten, um diese aufzulösen und ist dabei sehr intuitiv.

Natürlich ist Erlang auch keine Silverbullet, mit der sich alle Probleme lösen lassen. Grundsätzlich wird das Number Crunching, also das Verarbeiten von vielen Zahlen, als eine Schwäche von Erlang angesehen. Einerseits trifft das zu, da es Technologien gibt, die dies effizienter meistern – andererseits gilt das nur für Berechnungen, die sich nicht parallelisieren lassen. Bei einer Vielzahl von kleinen, nicht sequentiellen Berechnungen können die Stärken in der Parallelverarbeitung wieder überwiegen.

Die größte Schwäche von Erlang ist jedoch die Demographie: Während Unternehmen frisch gebackene Java-Entwickler in der Regel direkt von den Universitäten akquirieren können, gibt es vergleichsweise wenige Erlang-Entwickler auf dem Markt. Damit fällt nicht nur das Staffing besonders schwer, auch die Abhängigkeit von Personal oder einzelnen Dienstleistern und damit auch das Risiko steigen an.

Mit Elixir könnte sich das allerdings in Zukunft ändern. Die funktionale, nebenläufige Programmiersprache Elixir kompiliert genau wie die Sprache von Erlang sogenannten Beam-Bytecode, welcher auf der Erlang VM ausführbar ist. Somit profitiert Elixir von den Vorteilen der Basistechnologie und Laufzeitumgebung Erlangs, ist jedoch modern und zugänglich – insbesondere für eine breite Masse von Ruby-Entwicklern, die von der ähnlichen Konzeption bei höherer Geschwindigkeit und Skalierbarkeit angezogen wird. Die Unterschiede zwischen Erlang und Elixir verdeutlicht das folgende Code-Beispiel:

Hello World in Erlang

-module(hello).
-export([hello_world/0]).
hello_world() -> io:fwrite(„Hello, World!\n“).

Hello World in Elixir

defmodule MyModule do
def hello do
IO.puts „Hello, World!“
end
end

Ein Vergleich der Unterschiede zwischen Elixir und Ruby findet sich bei Github. Bei den Hilfestellungen, die es für den Ein- oder Umstieg gibt, hat sich die Elixir-Community ebenfalls ordentlich in Schale geworfen. Kein Vergleich zur wenig attraktiven Dokumentation von Erlang selbst: Mit Podcasts und bunten, einsteigerfreundlichen Web-Tutorials findet man schnell Zugang. Die Einstiegsbarriere der Erlang-Sprache wurde mit dem Release von Elixir also weitestgehend ad acta gelegt. Schon heute setzen Unternehmen wie Pinterest oder die Marketing-Software Moz auf Elixir, die im Juli 2018 veröffentlichte v1.7 der Sprache wurde fast 300 Millionen Mal heruntergeladen.

In diesem Zusammenhang kommt auch das von Chris McCord entwickelte Phoenix-Framework zur Geltung, das derzeit in einer stabilen v1.3 verfügbar ist: ein in Elixir programmiertes Webframework für die Erlang VM, das sich für die Erstellung leistungsfähiger und hochverfügbarer Webanwendungen anbietet. Phoenix lehnt stark an Ruby on Rails oder Django aus ­Python an und bietet deshalb einiges an Wiedererkennungswert. Selbst Java-Entwickler dürften das eine oder andere Server-Side-MVC-Framework kennen und ihre Muster dort wiederfinden.

Die stark wachsende Elixir-Community rückt Erlang immer weiter ins Rampenlicht. Es bleibt also zu erwarten, dass IT-Entscheider nicht mehr lange die demographischen Risiken befürchten müssen und stattdessen von der Stabilität, Skalierbarkeit und Entwicklungsgeschwindigkeit des Erlang-Ökosystens profitieren können. Trotz Elixir und Phoenix bietet es sich für ein möglichst tiefes Verständnis der Core-Technologie an, zunächst mit der Erlang-Sprache und dem OTP-Framework zu starten. Für Interessierte steht eine Vielzahl von stabilen Entwicklungsumgebungen zur Auswahl. Falls sich jemand im Emacs zu Hause fühlt, empfiehlt es sich, dort auch Erlang zu entwickeln. Hübscher geht es jedoch mit Intellij, Sublime oder Eclipse. Für die Verwaltung von Abhängigkeiten und das Durchführen von Testfällen stellt Erlang einen eigenen Werkzeugkasten zur Verfügung.