Elixir Programming Language

Deutsch

When there is need for high performance, scalability and availability of applications by using the parallelism that current hardware can offer, Erlang is on the table. It uses its own virtual machine, called BEAM. So in this aspect it is quite similar to Java and to most modern interpreted languages. They all use their VM under the hood. Erlang is functional and uses its own processes, which can be better understood by thinking of actors rather than of OS-level processes or threads. Communication between these Erlang processes is done by messages.

Since the JVM has become very popular in the IT world due to its maturity, diffusion and the knowhow in running it, there has been demand for better JVM programming languages than Java, which has lead to developments like Scala, JRuby, Clojure, Groovy, Ceylon and a few dozen more.

Elixir now brings the same idea to the Erlang world. The language is still Alpha and we will see were it will go. But the basic idea is having a Ruby-like syntax, some concepts and ideas from Clojure and off course the possibilities and paradigms from the Erlang world combined. So again it is possible to run many Erlang- or Elixir-processes and let them communicate via a highly efficient messaging system.

It will be interesting how this will compare to Erlang itself and to JVM-based solutions like the Akka-framework with Scala in terms of performance and stability.

Links:

Share Button

Elixir

English

Wenn es darum geht, hochperformante, skalierbare und hochverfügbare Applikationen zu entwickeln, die die Parallelisierungsmöglichkeiten der heutigen Hardware gut ausnutzen, ist Erlang ein Klassiker. Dieses verwendet eine virtuelle Maschine (BEAM), ähnlich wie Java und wie die meisten modernen interpretierten Sprachen. Erlang ist funktional und verwendet eigene Prozesse, die man eher als Aktoren denn als Betriebssystemprozesse verstehen sollte, zwischen denen via Messages kommunziert wird.

So wie in der IT-Welt die Java-VM sehr geschätzt wird, und sei es auch nur wegen ihrer großen Verbreitung und des Knowhows im Betrieb, so hat doch das Bedürfnis nach bessere Programmiersprachen für die Java-VM zu Entwicklungen wie Scala, JRuby, Clojure, Groovy, Ceylon und Dutzenden, weiteren Sprachen für die Java-VM geführt.

Diese Idee bringt nun Elixir in die Erlang-Welt. Die Sprache ist noch im Alpha-Stadion und wir werden sehen, was sich daraus entwickelt. Die Idee ist grundsätzlich, dass man eine Syntax verwendet, die sich an Ruby anlehnt, einige Ideen aus Clojure übernimmt und natürlich dann die Möglichkeiten und Paradigmen der Erlang-Welt in diesem Rahmen anbietet. Man hat also auch wieder beliebig viele „Prozesse“, wiederum im Sinne des Aktoren-Patterns, nicht als Betriebssystemprozesse oder -threads und eine Kommunikation via Messages.

Es ist sicher interessant, zu beobachten, wie sich das entwickelt und wie brauchbar es in Bezug auf Performance und Stabilität im Vergleich mit Erlang, aber auch mit JVM-basierten Lösungen wie dem Akka-Framework mit Scala sein wird.

Links dazu

Share Button

Serialisierung

Serialisierung ermöglicht es, Objekte mehr oder weniger vollständig und verlustfrei zu speichern oder über das Netzwerk zu übertragen. So etwas konnte man schon immer machen, aber früher musste man die Objekte „von Hand“ serialisieren, also jeweils die Funktionalität schreiben, die das leistet. Auch wenn es damals noch nicht Objekte waren.

Java hatte dann plötzlich so eine Serialisierung für (fast) alle Objekte an Bord und man mußte nur noch ObjectOutputStream und ObjectInputStream verwenden und konnte alle seine Objekte speichern und wieder zurücklesen. Sogar Referenzen, die mehrmals dasselbe Objekt referenzierten, wurden richtig behandelt. Neu war die Idee wohl nicht wirklich, andere Programmiersprachen konnten das schon viel früher, aber das hat kaum jemand gemerkt.

Dass dann doch eine gewisse Ernüchterung aufkam, soll hier nicht verschwiegen werden:

  • Die Markierung mit dem Serializiable-Interface ist konzeptionell eine schlechte Lösung, weil sie annimmt, dass abgeleitete Klassen autoamtisch auch serialisierbar sind, was nicht stimmt. Besser wäre ein Unserializable-Interface gewesen. Oder heute eine Annotation..
  • Mit dieser SerialVersionUID hat man eine Menge Ärger. Soll man sie immer nachführen, wenn sich das Interface ändert? Oder lieber den automatischen Mechanismen vertrauen? So oder so bleibt das Problem der inkompatiblen Versionen, das nicht wirklich gut gelöst und vielleicht auch nicht einfach lösbar ist.
  • Die Objektidentität geht bei der Serialisierung verloren. Man kann so leicht verschiedene Kopien von einem Objekt erzeugen. Das muss man bewusst behandeln.
  • Manchmal muss man doch manuellen Serialisierungs-Code schreiben, etwa für Singletons. Das vergisst man bei dem „alles automatisch“-Ansatz leicht, aber wenn man die Serialisierung selber schreibt, vergisst man auch, dass die schöne Copy-Paste-Orgie an genau dieser Stelle einmal eine Pause machen muss
  • Die eingebaute Serialisierung ist langsam
  • Es ist recht mühsam, aber durchaus möglich, ein Objekt in eine Byte-Sequenz zu serialisieren.
  • Das Format ist binär und nicht sehr gut lesbar. Schöner wäre es, wenn man den Serialisierungs-Mechanismus wählen könnte, z.B. JSON, XML, verschiedene Binärformate…

Es ist sicher gut, diese Serialisierung zur Verfügung zu haben und für viele Zwecke eignet sie sich auch halbwegs gut. Aber man sollte das ganze doch je nach Anwendungsfall kritisch hinterfragen und gegebenenfalls andere Ansätze in Betracht ziehen oder zumindest den Schwächen Rechnung tragen.

Share Button

Eigene Collection-Klassen

Wer braucht eigene Collection-Klassen? Java, Perl, Ruby, Scala, Clojure, sie alle haben gute Bibliotheken und da sind sehr schöne Collection-Klassen verfügbar und wenn die mitgelieferten nicht reichen, findet man noch passendere. Es lohnt sich zu suchen.
Gelegentlich braucht man komplexere Collections, z.B. Mengen, die noch eine Gruppierung in disjunkte Teilmengen aufweisen und wahlweise über die einzelnen Teilmengen oder als Gesamtmenge angesprochen werden können. Man denke an die Menge aller Räume in einem Gebäude und die Teilmengen der Räume in einem bestimmten Stockwerk. So etwas läßt sich leicht aus den vorhandenen Strukturen zusammensetzen, man muss nur noch schauen, dass man das entsprechende Interface für die Gesamtmenge implementiert.

Es gibt aber durchaus auch Fälle, wo man aus Performance-Gründen wirklich dezidierte Collections für den Anwendungsfall braucht und weder im Lieferumfang noch im Netz in der erfordelichen Qualität findet. Da typische Collection-Klassen sehr allgemein und flexibel gehalten sind, kann man Annahmen treffen und nutzen und so einiges abkürzen. Nur als Beispiel ließ sich einmal in Java eine Map durch eine eigene Implementierung ersetzen, die für die Schlüssel vom Typ long optimiert war und wesentlich weniger Speicher verbrauchte, solange die gespeicherten Wert-Objekte relativ klein waren. Da dies eine große Applikation war, die auf Servern wirklich das Memory aufgebraucht hat und man noch in der Begrenzung der 32-Bit-Welt agieren musste, ließ sich dadurch das Problem des zu großen Speicherverbrauchs in den Griff bekommen. Voraussetzung war natürlich, dass diese Tabellen einen großen Teil des Speichers belegten.

Share Button

WLAN-Router

Aus Sicherheits- und Durchsatzgründen ist es immer noch eine gute Idee, ein Netzwerk mit Kabeln anzulegen. Da wir so arbeiten, dass das Home-Verzeichnis auf einem NFS-Server liegt und alle Dateien auf diesem Rechner gespeichert werden und außerdem X11-Applikationen gelegentlich auf anderen Rechnern mit umgeleitetem Display laufen, ist ein zuverlässiges und schnelles und sicheres lokales Netzwerk sehr wichtig. Die Verkabelung im Gebäude ist dafür eingebaut worden.

Aber ein WLAN-Netzwerk ist trotzdem sinnvoll. Inzwischen können fast alle Mobiltelefone damit umgehen und man kann z.B. mit iO oder Skype telefonieren und das auch Gästen zur Verfügung stellen. Da Mobiltelefone und andere Mobilgeräte, die WLAN können, sowieso an anderen Orten direkt und ohne Firewall im Internet sind, habe ich eine Firewall zwischen WLAN und dem Kabelnetz eingefügt. Witzigerweise bieten die üblichen WLAN-Router zwar eine rudimentäre Firewall-Funktionalität, aber nur gegenüber der Netzwerkverbindung nach außen, weil anscheinend kaum jemand das Kabelnetz und as WLAN trennen will. Das lässt sich alles lösen, weil man natürlich die Firmware des WLAN-Routers austauschen kann und wenn nicht einen kaufen kann, bei dem das geht. Letztlich erwies es sich aber als einfacher, eine dezidierte Firewall zu kaufen und dazwischen zu schalten.

Für das WLAN selbst ist nun die Verschlüsselung eigentlich nicht sonderlich wichtig, sie erschwert es nur Gästen, das Netz zu benutzen. Da ja alle Geräte, die das WLAN benutzen, auch gelegentlich öffentliche WLAN- oder Mobilnetze verwenden, ist es sowieso notwending, die Geräte genügend abzusichern oder deren normaler Konfiguration zu vertrauen.

Hierzu kann man auch bei Bruce Schneier lesen, warum er sein
WLAN offen hat.

Share Button