Swift: Die eine Programmiersprache für „alles“ ?! (Teil2)

Die Evolution von Swift – the next level

Teil1

Es ist gut ein Jahr vergangen (Dezember 2015) seit Swift als Open-Source Programmiersprache das Licht der Welt(-Öffentlichkeit) erblickt hat. So finde ich, dass es mal wieder an der Zeit ist zu schauen, welche Evolution und Resultate diese recht junge Programmiersprache mittlerweile nach meiner ersten Bewertung und Prognose vom April 2016 in der Open-Source Entwickler Community gefunden hat. Um eine Sache vorweg zu nehmen: Mit Swift werden bereits produktive (Web-)Portal-Projekte umgesetzt (wie beispielsweise die Webseite des dänischen Triathlon-Events Ironman; Github-Source). So hat sich Swift tatsächlich in so kurzer Zeit von einer reinen Apple-Plattform Sprache (iOS, macOS, tvOS, watchOS) zu einem Linux-freundlichen Backend/Webframework-tauglichen Gesamtsystem entwickelt. Die aktuelle Version Swift3 genießt zudem große Kompatibilität im Segment der „kleinen ARM-Architektur Computer“ wie beispielsweise dem Raspberry Pi3 und dem dafür verfügbaren Ubuntu 16.04 als Betriebssystem; ergo die Software der Internet-Of-Things (IoT) kann ab jetzt tatsächlich ebenfalls mit dieser hochmodernen und performanten Programmiersprache entwickelt werden.

Mit der Portabilität auf anderen Plattformen jenseits von Apple hat die Open-Source-Community bei Swift3 somit bisher sehr gute Arbeit geleistet. Apropos Apple: Seit Einführung von Swift als alternative „gleichberechtigte“ Programiersprache zu Objective-C hat Apple mit der Community nun erstmals seit Swift3/Xcode8.x begonnen zusätzliche neue „Typen“ in den etablierten System-Frameworks (Foundation) einzuführen, die ausschließlich nur noch in Swift (nicht mehr in Objective-C) nutzbar sind, dazu gehören z.B. URL, URLRequest, Date, Data, UUID, etc. .

Einer der (technischen/strategischen) Hintergründe dieser sinnvollen Swift-only Entscheidung von Apple ist der, dass Swift sogenannte moderne Value-Types unterstützt  (in den Beispielen oben sind das structs) und das über 30 Jahre alte und entsprechend in die Jahre gekommene Objective-C hier lediglich auf Klassen-Objekte  (mit entsprechendem Overhead in Speichermanagement/Heap-Allokierung und weiteren Sprach-Feature und Performance-Einschränkungen) angewiesen ist; auf gut deutsch: Apple hat erkannt dass die“parallele“ Feature und API Kompatibilität/Interportabilität zwischen Objektive-C und Swift nicht auf Dauer zu halten ist und hat diese „künstliche Hürde“ nun endgültig aufgelöst um dem modernen Swift eine (Objective-C) unabhängige Weiterentwicklung insbesondere auch auf den eigenen Plattfromen zu gestatten. Jetzt ist es offiziell und keine Glaubensfrage zwischen eingefleischten Objective-C und Swift Entwicklern für die Apple Plattformen mehr; Wer heute noch bei anstehenden Projekten auf Objective-C als Programmiersprache setzt, hat entscheidende Nachteile gegenüber den Neuerungen und System-API-Weiterentwicklungen die sich nun vermehrt nur im Swift-Kosmos abspielen werden. Glücklicherweise ist Swift (syntaktisch c,Java,C#-nah) eine Programmiersprache, die man wesentlich schneller erlernt (als man braucht um den noch-Objective-C Einsatz rechtzufertigen 😉 ) und somit spätestens jetzt ist ein dringend empfohlener Umstieg angeraten (falls noch nicht geschehen); direkt in einem laufenden legacy Objective-C Projekt können Swift-Dateien hinzugefügt und parallel zur bisherigen Objective-C code-base genutzt werden. Bei Neuprojekten wäre es als grob fahrlässig einzustufen, diese heutzutage mit den bisherigen Geschehnissen und Zukunftsprognosen noch mit Objective-C zu starten. Ein Beispiel der „deutlich ausseinander laufenden“ Unterstützungen und Funktionalitäten von Objective-C und den neueren Swift Typen ist NSData (in Objective-C/Swift nutzbar) und Data (Swift only) – hier hat der „alte“ Typ lediglich 30 properties/methods, während der „swift only“ Typ über 130 aufweist.

Meilensteine der Swift Evolution

Ab Swift3 hat die intensive Stabilisierung der Sprachsyntax nun Früchte getragen so dass Chris Lattner (Hauptentwickler und „Vater“ von Swift) nun eine neue Ära der „Source Compatibility“ ausgerufen hat. Bedeutet zu deutsch: Ab der nächsten Version von Swift (3.1 etc.) wird es keine Source-Code Inkompatibilitäten von bisher geschriebenem Swift3 Code mehr geben; also die Notwendigkeit von teils größeren Code-Migrationen in Projekten (in xCode als Migration-Assistent auffindbar) wie bei den Anfängen von Swift1 zu Swift2 zu Swift3 wird es nicht geben – sehr zu Freuden der bisher zum Teil dadurch geplagten Entwickler. Diese Ankündigung macht auch den Weg frei weitere Tools rund um swift bei Apple und außerhalb weiter zu optimieren und gezielt zu stabilisieren. (z.B. static-analyzer, code-completion und refactoring-facilities in xCode)

Nicht nur die Sprachsyntax selbst wurde nun entscheidend stabilisiert (Swift-Bücher dürfen nun gedruckt werden ohne die Angst zu haben vor dem Ankommen in der Buchhandlung inhaltlich weit überholt zu sein – Auflage xyz  😉 ). Auch an der sogenannten „ABI Stability“ der Swift Standard-Library wird nun bis zum nächsten großen Swift4 Release in diesem Jahr gezielt gearbeitet; das Resultat wäre dann eine binary-Kompatibilität von Source-Code der mit einer „älteren“ und einer „neueren“ Version von Swift kompiliert wurde – ein weiterer entscheidender Meilenstein, der eine zwangsweise Re-Komilierung von bisher geschriebenen Code nicht mehr voraussetzt; Die große Stunde von der Entwicklung von third-party-libraries, die binär ausgeliefert werden können – ohne jede Swift-Iteration aktiv warten zu müssen. Die ABI-stability hätte auch den Vorteil dass nicht jede Anwendung ihre eigene kompilierte Variante der Swift-Standard-Libary mit sich tragen muss, sondern dass diese als zentraler Bestandteil von zukünftigen Betriebssystemen (System-Framework/Module bei iOS, macOS, etc.) von allen zukünftigen Swift4-Anwendungen mitgenutzt werden kann, ergo kleinere resultierende App-Binaries.

Jenseits von Apple/macOS und Linux

Das Jahr 2016 hat auch Microsoft intensiv genutzt um im Bereich Open-Source Aktivität mitzumischen. Zum einen haben sie es mit dem WSL-Projekt geschafft in ihrem aktuellen Betriebssystem Windows 10 ein Ubuntu/Linux-Subsystem einzuführen, das es ermöglicht viele (Open-Source) Kommandozeilen-Tools, die es nur für Linux gibt, direkt unter Windows (ohne diese neu zu kompilieren!) emuliert auszuführen. Zum anderen haben sie einen leichtgewichtigen Source-Code Editor, ja quasi eine flexible/erweiterungsfreudige Mini-IDE (VisalStudio Code) für alle 3 großen Plattformen (Linux, macOS, Windows) kostenlos zur Verfügung gestellt. Ein sehr löblicher Schachzug, wie ich finde, der die Entwickler-Communities noch stärker zusammenschweißt, unabhängig auf welcher und für welche Plattform entwickelt wird und mit welcher Technologie oder Framework.

Apropos Frameworks; seit dem ersten Teil meines damaligen Swift Artikels hat sich neben den genannten größeren Swift Web-Frameworks (unter anderem auch das Kitura von IBM oder Perfect) mittlerweile auch ein neues (laut eigener Aussage das beliebteste) Swift Web-Framework herauskristalisiert und hat die größte Swift Webframework-Community etabliert: VAPOR !

Apple hat mittlerweile einen so großen Gefallen an dem Gedanken Swift als die neue performante Web- und Backend Programmiersprache zu etablieren, dass Sie regelmäßig die Contributoren dieser Web-Frameworks zu sich auf die Bühne einlädt (Video: IBM bei der WWDC-Entwicklerkonferenz 2016) bzw. den Status derer Frameworks auf dem Apple-Campus präsentieren lässt (Video: Introduction to Vapor @ apple). Neben der eigentlichen Swift-Evolution hat Apple nun mit dem Thema „server side swift“ ein eigenes Subprojekt mit der Community gestartet, so dass die etablierten Swift Webframeworks noch mehr Server-API-seitige Unterstützung, Support und Funktionalität zukünftig aufweisen werden.

Windows 10: Visual-Studio Code mit Ubuntu-Subsystem/WSL-bash bei der Entwicklung eines -Swift3/Vapor-Webframework Projektes

Erstaunlicherweise kann man mit der oben im Bild dargestellten Toolchain tatsächlich (ohne den notwendigen Einsatz von Apple-Hardware mit macOS oder der Installation einer Linux Distribution bzw. VM oder Container) eine Swift Webanwendung unter Windows entwickeln, kompilieren und ausführen, entsprechendes Sytax-Highlighting für Swift und für die view/html template-Sprache leaf ist auch in Form von Extensions in dieser Mini-IDE (VisualStudio-Code) hinzufügbar. (danke Microsoft)

Was kann man zu der „Mächtigkeit“ des Vapor/Swift3-Frameworks sagen?! Es ist  production-ready, hat die Unterstützung zu diversen etablierten Web-Systemen und Technologien an board (z.B. Redis, Mysql, Postgres, Mustache, MongoDB, nginx, uvm.), ist flexibel und ausbaufähig in alle Richtungen, hat Middleware/Authentifizierungen/Sessions und einen ORM-Layer für die Datenpersistierung dabei, Websockets-Support, hat eine großartig wachsende Community, ist komplett in Swift3 geschrieben (keine C-Library-Dependencies wie beispielsweise bei der Webserver-Implementierung beim derzeit gehypten NodeJS/ExpressJS-Webframework) und hat eine hervorragende und mächtige (typesafe) Routing-Engine; ein Beispiel:

Zusammenfassend kann man sagen, mit Vapor hat man ein getestetes und im produktiven Einsatz befindendes Swift3 Web-Framework, das sich bereits jetzt hinter keinen der jahrelang etablierten Webframeworks aus der Ryby, Python, PHP und NodeJS/ExpressJS Ecke verstecken muss; Im Gegenteil; durch die neuen Möglichkeiten und Eigenschaften, die diese neue native Programmiersprache mit sich bringt, hat es die Chance ganz neue innovative Entwicklungen bei der Weblandschaft der Zukunft einzuschlagen. Um die Performance der „server side swift“ Bewegung weiter zu optimieren, wird bereits mit den ersten Frameworks versucht das aus der Programmiersprache GO bekannte hochperformante Threading-Modell der Coroutines in den Swift Web-Frameworks zu adaptieren. Bereits jetzt kann sich die overall-Performance von Swift Webanwendungen mehr als sehen lassen. Wohin die Reise mit Swift und zukünftiger Web-Entwicklungen geht, zeigen die unteren Zahlen, als auch die bisherigen nur 1 Jahr andauernde Open-Source Bestrebungen der Community bereits sehr deutlich. Was meint ihr? Schreibt es in die Kommentare unten.

Swift hat den größten Technologiewastum auf Github (2016)

Den schnellsten eigenen Einstieg in die Swift-Webframework Serverentwicklung bekommt ihr mit diesem vorbereiteten und griffbereiten Docker-Container-Image. Viel Spaß beim Ausprobieren.