Scala Days
Die Hauptkonferenz begann am 12.06. mit der Keynote von Martin Odersky. In seiner “Tour of Scala 3” stellte er vor, welche Änderungen in Scala 3 zu erwarten sind und schaffte es, dies auch denjenigen zu vermiteln, die sich vorher nicht intensiv mit Dotty beschäftigt hatten, der nächsten Generation des Scala-Compilers.
Zudem präsentierte Odersky eine überzeugende Strategie für die Migration von Scala 2 zu Scala 3. Dadurch dass mit Scala 2 kompilierter Code von Scala 3-Projekten konsumiert werden kann, ist kein großer Bruch zu erwarten, wie es etwa in der Python-Community bei der Einführung von Python 3 der Fall war.
Deutlich wurde außerdem, dass Scala 3 eine für Neulinge leichter zugängliche Sprache sein wird. Viele Anwendungsfälle mussten bisher als Patterns umgesetzt werden unter Verwendung sehr generischer Sprach-Features. Hier bricht Scala 3 mit der Philosophie eines möglichst minimalistischen Sprachkerns. Beliebte Anwendungsfälle, etwa algebraische Datentypen oder Typklassen, haben ihre eigene Syntax spendiert bekommen. Dies ermöglicht es Code zu schreiben, der die dahinter stehende Intention deutlich stärker zum Ausdruck bringt als bisher.
Man darf gespannt sein, ob es mit Scala 3 gelingt, mehr neue Entwickler*innen in die Scala-Community zu holen.
Möchte man mit einer Sprache möglichst viele Leute erreichen, ist es jedoch nicht ausreichend, diese leicht erlernbar zu machen. Ohne gutes Tooling wird man viele Interessierte abschrecken und schnell wieder verlieren. Das hat man auch beim Scala Center verstanden. Ólafur Páll Geirsson zeigte in seinem Vortrag “Metals: rich code editing for Scala in VS Code, Vim, Emacs and beyond”, wie weit gediehen die arbeiten an metals, einem Language Server für Scala, bereits sind: Autocompletion, Type Hints, Go to Definition und andere Features stehen damit allen Nutzer*innen der Code-Editoren wie VS Code, Atom, SublimeText, Vim oder Emacs zur Verfügung. Wer also vor schwergewichtigen IDEs wie IntelliJ IDEA zurückschreckt, kann nun in gewohnter Umgebung arbeiten ohne auf diese essenziellen Code-Editing-Funktionalitäten verzichten zu müssen.
Gutes Tooling, eine möglichst zugängliche Sprache. Das ist alles hilfreich und wichtig. Ein leider sehr unterbewertetes Thema in diesem Zusammenhang ist jedoch das Lehren. Dabei ist es essenzieller Bestandteil unseres Berufs, anderen etwas beizubringen; seien es Junior-Entwickler*innen im eigenen Team oder Scala-Neulinge auf einem ScalaBridge-Workshop (siehe dazu weiter unten). Und gerade weil das Thema viel zu wenig Beachtung findet, war Noel Welshs Vortrag “Techniques for Teaching Scala” so wichtig. Viele der erläuterten Techniken sind dabei nicht einmal Scala-spezifisch, so dass der Vortrag allen ans Herz gelegt sei, die in der IT-Branche anderen etwas beibringen. Wirklich großartig war der Hinweis darauf, dass für Anfänger*innen wichtig ist zu lernen, dass es normal ist, Fehler zu machen, und wie man mit diesen umgeht. Compiler-Fehlermeldungen interpretieren oder Debugging gehören zu unserem Alltag und sollten deshalb von Mentor*innen nicht ignoriert werden.
Kelley Robinsons Vortrag “Building a Better Scala Community” ergänzte diese Themen perfekt, indem sie verdeutlichte, wie wichtig es ist, eine offene und inklusive Community zu haben, in der sich auch Menschen aus unterrepräsentierten Gruppen wohl fühlen. Um dies zu erreichen, ist es wichtig, Empathie zu üben (“practice empathy”), Vertrauen aufzubauen (“build trust”) und andere Menschen zu befähigen (“empower others”). Zu allen drei Punkten gab Kelley Robinson wertvolle konkrete Tipps. Zum Abschluss der Konferenz wurde sie außerdem mit dem Phil-Bagwell-Award ausgezeichnet, unter anderem für ihre herausragenden Leistungen für mehr Inklusivität in der Scala-Community als Gründerin von ScalaBridge.
Mit der Entwicklung im Rahmen von Open-Source-Communities beschäftigten sich auch die Beiträge von Holden Karau und Bogdan Vasilescu. Holden Karau – bekannt unter anderem für ihre Beiträge zu Apache Spark – erinnerte daran, dass es viele Open-Source-Projekte gibt, die Unterstützung von Freiwilligen benötigen. Doch angenommen, man hätte ein Open-Source-Projekt ausfindig gemacht, das man interessant und deren Community man gar sympathisch findet, wie kann man beitragen? Wie gelingt der Einstieg am Besten? Während viele andere dazu raten, mit den einfachsten verfügbaren Entwicklungsaufgaben oder Beiträgen zur Dokumentation einzusteigen, schlägt Karau den Einstieg über Code-Reviews vor. In vielen Projekten warteten Verbesserungen oder Fehlerkorrekturen allzu lang auf ein Review und würden deshalb spät oder gar nicht integriert. Die Durchführung von Reviews sei hingegen eine gute Möglichkeit, mit erfahreneren Entwickler*innen des Projekts zu interagieren, Fragen zu stellen und zu lernen.
Doch was motiviert Menschen eigentlich, sich im Open-Source-Bereich zu engagieren? Wer engagiert sich dort? Und wie wahrscheinlich ist es, dass die Bibliotheken, die man nutzt, auch in Zukunft gepflegt werden? Diesen und weiteren Fragen ging Bogdan Vasilescu in seiner Keynote nach. Angesichts der Tatsache, dass Open-Source-Produkte aus der Software-Entwicklung auch kommerzieller Software nicht mehr wegzudenken sind, sind dies zweifellos wichtige Fragen. Vasilescu präsentierte empirische Forschungsergebnisse basierend auf Daten von GitHub und PyPI, aber auch auf eigenen Fragebögen. So stellte er beispielsweise fest, dass Open-Source-Produkte, die von einem Unternehmen entwickelt oder unterstützt werden, im Schnitt nicht etwa eine höhere, sondern eine niedrigere Überlebenswahrscheinlichkeit aufweisen als solche, die nur von Freiwilligen getragen werden. Ebenfalls negativ wirken sich allzu viele (auch indirekte) Abhängigkeiten zu anderen Produkten oder Bibliotheken aus. Schließlich zeigte Vasilescu auch Wege auf, das eigene Open-Source-Projekt und seinen Code besser zu machen: sogenannte Badges bieten die Möglichkeit, direkt auf der Hauptseite des Repositories einige Kerninformationen anzeigen zu lassen. Beispielsweise können in einem Badge Informationen über die Lizenz, den Code Style, die Testabdeckung, die Aktualität der Abhängigkeiten oder die durchschnittliche Zeit bis zur Lösung eines Issues angezeigt werden. Vasilescu fand, dass die Badges insgesamt eine Wirkung auf Projektmitglieder haben und diese am größten ist, wenn eine Analyse bzw. Berechnung zugrunde liegt.
Contributors Summit
Vor den Scala Days gab es eine Reihe von Community-Events, die weniger Vortrags-, sondern eher Workshop-Charakter hatten. Beim Contributors Summit am Montag kamen Menschen zusammen, die bereits Beiträge zu Scala geleistet haben oder dies wollen, um gemeinsam die Zukunft von Scala zu gestalten. Wenig überraschend hat dabei das Thema Scala 3 den größten Platz eingenommen. Martin Odersky, seine Mitarbeiter und Interessierte haben darüber diskutiert, welche neuen Features implementiert oder geplant sind und wie man die Migration von Scala 2 möglichst reibungsfrei umsetzt. Insgesamt entstand der Eindruck, dass Scala 3 stark Fahrt aufnimmt und man auch auf Rückwärtskompatibilität Acht gibt. Schwierig wird es allerdings sein, das gesamte Ökosystem von Bibliotheken auf Scala 3 zu migrieren. Daher kann der derzeit noch experimentelle Dotty-Compiler für Scala 3 auch die Kompilate von Scala 2 interpretieren, sodass Applikationen schon heute als Kombination von Scala-2-Bibliotheken und Scala-3-Anwendungscode realisiert werden können.
Ferner gab es noch Workshops zu den Themen Tooling, Scala im Unternehmensumfeld, Big Data und Einsteiger*innenfreundlichkeit.
ScalaBridge
Am Dienstag fand ein ScalaBridge-Workshop statt. Dabei handelt es sich um einen Kurs für Anfänger*innen, der sich besonders an Menschen unterrepräsentierter Gruppen richtet. Daniel und Lars waren als zwei von vier Mentoren vor Ort, die ungefähr zehn Mentees betreut haben. Als Curriculum wurde das Buch Creative Scala von Dave Gurnell und Noel Welsh benutzt, wo Scala anhand einer einfachen Grafikbibliothek eingeführt wird. Die Teilnehmer*innen nutzen ein gängiges Setup aus IntelliJ und sbt, um Bilder zu erzeugen. Der Vorteil gegenüber reiner konsolenbasierter Programmierung besteht darin, dass selbst absolute Neulinge sofort etwas “sehen” und damit experimentieren können.
Scala Spree
Parallel zu ScalaBridge gab es eine Scala Open Source Spree, bei der Interessierte gemeinsam mit Maintainern zusammen Änderungen zu Open-Source-Projekten vorbereiten und einbringen können. Da die Scala Days dieses Jahr in Lausanne stattfanden, stand die Scala Spree unter den Zeichen von Projekten, die an der EPFL entwickelt werden, z.B. Scala.js und Metals, die auch thematisch bei der Hauptkonferenz vertreten waren.
Typelevel Summit
Schließlich rundete der Typelevel Summit am Freitag die Woche der Scala Days ab. Organisiert wurde dieser hauptsächlich von Lars. Es gab eine Reihe von Vorträgen zu hören, die thematisch eher zu Typtheorie gehören, so z.B. ein Vortrag über das System Granule, in dem die sichere Verwendung von Ressourcen (Öffnen–Verwenden-Schließen) vom Typsystem erzwungen wird. Doch es gab auch Beiträge über Diversität und Tooling im Scala-Ökosystem zu hören.