Dari und ich durften vom 15. bis 17. November an der GOTO Konferenz in Berlin teilnehmen.
TL;DR
Bevor ich ein paar Insights zu den einzelnen Themen gebe, hier mein Fazit zur GOTO Berlin: eine Entwickler-Konferenz der Extraklasse! Internationale Top-Speaker und – mit dem BBC direkt am Alexanderplatz – eine ideale Location! Auch aus fachlicher Sicht kann ich die GOTO nur wärmstens empfehlen. Dominierend waren, zumindest in meiner Track-Wahl, die Bereiche Container & MicroServices Security (Workshop), Programming Languages und Machine Learning. Beim Workshop gibt es ganz konkrete Takeaways, was man beim Thema Sicherheit im Bereich Docker und Kubernetes auf dem Zettel haben sollte (insb. Linux Namespaces!!). Wer hierzu weitere Infos haben möchte, kann sich sehr gern bei mir melden.
Hier nun die Key-Takeaways aus den Sessions, die ich mir herausgepickt hatte:
4 Jahre Monitoring mit Prometheus bei SoundCloud
Prometheus kann eine sinnvolle Ergänzung zum Logging und dem ELK-Stack sein und ist ab einer gewissen Last-Größenordnung ohnehin quasi unverzichtbar. Insbesondere Whitebox-Monitoring ermöglicht Warnungen zum Zustand einer Komponente „bevor es zu spät ist“. Prometheus ist bei entsprechenden Nicht-Funktionalen Anforderungen also definitiv einen Blick Wert. Nagios kann da schon lange nicht mehr mithalten.
WebAssembly (WASM)
Die beiden Compiler-Experten Ben Titzer und Andreas Rossberg, beide u.a. V8 Core Team-Member und Tech-Leads bei Google, stellten den Standard WebAssembly vor. Praktisch war dabei, dass Ben Titzer auch einer der Gründer des WebAssembly-Projekts ist (zusammen mit jemandem bei Mozilla). Ohne zu sehr in die Details der WASM Stack Machine zu gehen, hier eine kurze Einschätzung von mir: es wird in den nächsten Jahren ein hochinteressantes Thema im Bereich Frontend sein. Aktuell sind als Quellsprachen C++ und Rust unterstützt, aber es werden weitere Sprachen folgen, die als Compile-Target WASM anbieten. Alle großen Browser unterstützen den W3C-Standard bereits. Mit der weiteren Etablierung des Binärformats gehört das Transpilieren nach JavaScript hoffentlich in den nächsten Jahren einmal der Vergangenheit an.
Why is Rust successful?
Rust-Guru Florian Gilcher gab einen schönen Abriss zur Sprache. Das Timing des Vortrags war ebenfalls gut, hatte ja Mozilla ein paar Tage zuvor eine neue Firefox-Version veröffentlicht. Dank der neuen CSS-Engine „Stylo“, komplett in Rust geschrieben, ist Firefox nun deutlich schneller als zuvor. Hier musste das Stichwort „Fearless Concurrency“ fallen – ein wichtiges Credo von Rust. Wer mehr zum Thema Rust erfahren will und sich dafür interessiert, was Rust so einzigartig im reichhaltigen Ökosystem an verfügbaren Programmiersprachen macht, der kann gerne auf mich zukommen.
Kleiner Spoiler: das Typsystem ist sehr leistungsfähig und kann damit zur Compile-Zeit formale Garantien liefern, dass ein Programm keine Race-Conditions enthält. Alles in allem geht Rust hier einen Weg, den man vielleicht höchstens im Bereich der akademischen Sprachen kennt. Hat hier jemand gerade „Haskell“ gesagt.. ? Rust ist im Gegensatz zu diesen Sprachen produktiv in signifikantem Ausmaß bei Mozilla, aber zum Beispiel auch in Core Infrastruktur-Komponenten bei Dropbox im Einsatz. Man wird von Rust also noch so einiges hören.
Make Web Apps Fun to Build and Easy to Refactor witch Elm
Wir bleiben im Bereich typsicherer Sprachen, wechseln aber auf’s Frontend: Elm hat die Dev-Experience in dem Bereich vor ein paar Jahren revolutioniert. Berühmte Adopters: Redux/Flux-Architecture bei React; vuex bei vue.js oder Reagent unter ClojureScript. Auf die Frage, wann das nächste Major-Release zu erwarten sei (ggf. mit server-side pre-rendering), konnte der Speaker verständlicherweise keine genaue Auskunft geben. Das liegt wohl in den Händen des Lead-Entwicklers Evan Czaplicki. In dem Kontext sehe ich auch eine der größten Schwächen von Elm. Es wird tatsächlich sehr stark von einem Hauptentwickler vorangetrieben.
Wer keine neue Sprache lernen will um in den Genuss von Typsicherheit und Absenz von NullPointer-Exceptions zu kommen, dem rate ich mal einen Blick auf TypeScript in Verbindung mit vue.js oder, wer es gerne enterprise-mäßig mag, ggf. auch Angular zu werfen. In Kombination mit allen TypeScript Compiler-Strict-Flags und unter Einbeziehung Persistenter Datenstrukturen wie immutable.js kann auch hier ein solides Maß an Typsicherheit erzielt werden, ohne JavaScript komplett den Rücken zu kehren.
One Language, all tiers: Developing Multiplatform Projects with Kotlin
Dmitry Jemerov vom Kotlin-Team bei Jetbrains gab am Tag der Ankündigung von Kotlin/Native 0.4 einen Überblick zum aktuellen Stand. Die Zielplatform JVM ist ja für Server-Developer, aber auch für Android-Entwickler, bei Kotlin schon gut etabliert. Entwicklungen gab es in den letzten Monaten im Bereich von JavaScript als Zielsprache und nun liegt eben mit Kotlin/Native auch eine Unterstützung von iOS und anderen Plattformen vor. Jetbrains will hier also neben der JVM mit Kotlin auf allen relevanten Targets bei Entwicklern punkten und investiert dort massiv in die Entwicklung.
Aktuell nutzt Kotlin/Native Reference-Counting für’s Memory-Management wenn kein Garbage-Collector wie auf der JVM als Zielplattform verfügbar ist. Ob das auch in Zukunft so bleibt oder ob man eher Ansätze wählt, die auch Rust ohne Runtime geht, bleibt abzuwarten. Die 0.4 Version von Kotlin/Native gibt den Entwicklern hier wohl noch einiges an Raum zum Experimentieren.
