Zurück zur Zukunft
Nach meinem letzten Rant historischen Überblick über Cobol Java habe ich mir weitere Gedanken gemacht wie ich in Zukunft programmieren möchte. Wir werfen einen Blick auf folgende Programmiersprachen:
- Rust
- Kotlin
- Go
- Elixir
- TypeScript
und schauen, was diese auf der bestehenden Basis besser machen. Gerne hätte ich noch Scala und Swift mit reingenommen, dabei scheint mir erstere mehr eine Computerphilosophie zu sein, als eine produktionsfähige Sprache und letzteres wird glaube ich im Moment von Apple eher zu Grunde gerichtet, wenn man den Stimmen aus der Community glauben kann.
Meine ersten Programmiersprachen waren BASIC und Pascal. Besonders Pascal hatte eine Klarheit und Eleganz, die mich bis heute begleitet. Ich hatte sogar einmal Gelegenheit, Niklaus Wirth persönlich zu treffen. Als er über Oberon sprach, bewegte seine Begeisterung das Publikum. Er ist im letzten Jahr verstorben. Seine Ideen bleiben: Eleganz und Klarheit. Nebenbei: Meine Kinder heißen Pascal und Linus. Die Entscheidung fiel mir nicht schwer.
Basic hatte in den 1990er Jahren noch ein Wiederbelebung durch Microsoft erfahren in Form von Visual Basic. Programmierer feierten noch die Ungarische Notation von Charles Simonyi, ein Relikt aus einer Zeit, als IDEs noch keine Autovervollständigung hatten und Typenverfolgung ein ferner Traum war. Sie sollte helfen, aber sie tat weh. Und sie ist wie ein schlechter Haarschnitt aus den 90ern: Damals vielleicht sinnvoll, heute nur noch peinlich.
Kotlin: pragmatisch, elegant, modern
Die Java VM ist zweifellos das Herzstück des Java-Ökosystems. Sie emuliert auf Intel-Prozessoren eine RISC-Architektur, war am Anfang quälend langsam und braucht immer noch ihre Zeit zum Starten. Das machte sie natürlich ungeeignet für CLI-Tools, aber gut geeignet für Desktop-Anwendungen und Applikationsserver, die typischerweise länger laufen. Mit den Optimierungen, die die VM inzwischen erfahren hat, läuft die Software schneller als manuell optimierter C++-Code und mit ihren zahlreichen Instrumentierungen und Schnittstellen in die Unternehmenswelt integriert sie sich hervorragend.
Inzwischen sind mit Kotlin und Scala weitere Sprachen angetreten, die in Bytecode der JVM kompiliert werden können. Während Scala mehr eine theoretische Computerphilosophie darstellt, ist Kotlin eine pragmatische Sprache, die moderne Features wie Null-Sicherheit und Dataclasses bietet.
- Null-Sicherheit eingebaut:
?
statt “NullPointerException
as a Service” - Dataclasses:
data class User(val name: String)
statt 50 Zeilen Boilerplate - Extension Functions: Methoden auf bestehenden Klassen, ohne Vererbung oder Factory-Orgien
- Top-Level-Funktionen: Du brauchst keine Klassen, wenn Du keine brauchst
- Coroutines: Superleichte Concurrency, viel einfacher als Java-Threads
Minimalistisch, lesbar, pragmatisch. Kotlin will, dass Du Code schreibst – nicht Konventionen abarbeitest. Kotlin ist wie jemand, der Java liebt, aber trotzdem auszieht, um’s besser zu machen.
Typescript: Javascript mit Anschnallgurt
Nachdem ich einige Zeit mit Coffeescript hantiert hatte, weil Javascript nach Jahren des Python-Codens einfach wirklich gegen den Strich ging, kam ECMAScript 6. Auf einmal machte Javascript plötzlich wieder Sinn und Spaß!
Was an CoffeeScript gut war:
- Kürzere Syntax: Kein function, kein var, kein Klammern-Wirrwarr.
- Arrow Functions, Default-Parameter, Destructuring – alles vor ECMAScript 2015.
- List Comprehensions:
[x * 2 for x in list when x > 5]
– yeah! - Indentation statt Klammern: Klarer, lesbarer Code – fast wie Python
ES6 hat fast alles übernommen, ohne einen zusätzlichen Transpiler darufzusetzen. Damit verschwand CoffeeScript sang- und klanglos. Anscheinend vermissten aber genug Entwickler die Möglichkeit, ihre eigenen Typen zu definieren und zu überprüfen. TypeScript wurde entwickelt, um diese Lücke zu schließen und die Typsicherheit von Java und C# in Javascript zu bringen. Aber hey, wir danken CoffeeScript für viele gute Ideen, die JS heute selbstverständlich hat. Es war der mutige Vorläufer mit Hang zur Syntax-Rebellion.
Elixir: Hipster mit Ruby-Flair und Erlang-Power
Die JVM ist nicht die einzige, die richtig was wegschafft. BEAM, die virtuelle Maschine von Erlang, wurde ursprünglich entwickelt, um hochverfügbare Telefonsysteme zu betreiben – also Systeme, die niemals abstürzen dürfen und Millionen paralleler Verbindungen handhaben können. In ihrer Architektur lebt dieser Anspruch weiter: leichtgewichtige Prozesse, fehlertolerantes Design und ein “let it crash”-Prinzip, das nicht auf Kontrolle, sondern auf Isolation setzt.
Wer funktionale Programmierung kennt – etwa aus Haskell –, erkennt viele vertraute Konzepte: Immutability, Pattern Matching, rekursive Denkweise, starke Ausdruckskraft. Doch wo Haskell akademisch bleibt, ist Erlang pragmatisch – es geht nicht um mathematische Eleganz, sondern um laufende Systeme.
Elixir bringt nun das Beste aus beiden Welten: die Robustheit und Laufzeit von Erlang, die Ausdrucksstärke und Eleganz funktionaler Sprachen wie Haskell und eine klare, moderne Syntax, die an Ruby erinnert. Elixir ist lesbar, elegant und enthält kaum Boilerplate. Der|>
Pipe-Operator ist ein Traum für Datenflüsse. Kein Klammer-Gemetzel, keine return
-Flut. Immutable Data, Pattern Matching, Tail Recursion, aber nirgends dogmatisch – Elixir will, dass Du was baust, nicht predigst.
“Elixir ist wie ein Spock, der lächelt – logisch, effizient, aber mit Stil.”
Seit ich die ersten Experimente mit dem Phoenix-Framework gemacht habe, möchte ich eigentlich nicht zu Javascript zurück. Allerdings ist Elixir noch ein Nischenprodukt: Die JVM- und Node-Welt dominiert im Backend, es gibt wenige Entwickler und viele Firmen schrecken vor funktionaler Programmierung und ungewohnter VM zurück. Aber: Wenn Du heute was hochverfügbares, parallel skalierendes, elegant lesbares bauen willst und keinen Bock auf Kubernetes, Async-Hölle oder Java-Konglomerate hast, dann bleibt Dir: Elixir.
Rust und WebAssembly: die neue VM im Browser
Java hatte einst die Vision: „Write once, run anywhere“. Die Realität war: „Write once, debug everywhere“. Mit Rust und WebAssembly (Wasm) nähert sich dieses Versprechen nun der Erfüllung – nur 25 Jahre später und mit ernstzunehmender Technik. Rust kompiliert in Wasm, das in allen modernen Browsern läuft – schnell, sicher, ohne Plugin. Damit entsteht eine neue Art von Laufzeitumgebung direkt im Browser: kompakt, typensicher, memory-safe.
Kein Garbage Collector. Kein JIT. Kein ClassLoader. Nur Performance.
Ein statisch kompilierter Rust-Code läuft in der gleichen VM wie Python (Pyodide), C/C++ (Emscripten), und bald auch Go, .NET, und mehr – alles gleichberechtigt neben JavaScript, aber ohne dessen Altlasten.
Go: Die Runtime, die einfach läuft
Während Java sich in XML-Konfigurationen verirrte und JavaScript Typen nur simuliert, verfolgt Go einen anderen Ansatz: Kompilieren, ausführen, fertig.
Go braucht keine virtuelle Maschine, kein Classpath, kein Transpiler – nur ein einziges statisch gelinktes Binary. Das Ergebnis ist eine Runtime ohne Runtime, die trotzdem genug mitbringt: Garbage Collection, Concurrency mit Goroutines, und Cross-Compilation auf Knopfdruck.
Go ist das Bash-Script mit Diplom.
Was Go fehlt: fancy Metaprogrammierung, Makros, eleganter Pattern-Matching-Syntax. Was Go bietet: eine solide, pragmatische Plattform, auf der man Infrastruktur, APIs und Werkzeuge baut, die nicht explodieren, wenn man das Interface ändert.
Fazit: Es gibt kein Fazit
Das war erstmal ein Überblick. Vielleicht mache ich ja noch eine kleine Serie daraus. callback()
later!