- Swift unterstützt neben Apple-Plattformen auch Linux, Windows und weitere Systeme
- Mit dem Swift Static Linux SDK lassen sich vollständig statisch gelinkte ausführbare Dateien ohne externe Abhängigkeiten bauen
- Diese können auf allen Linux-Distributionen ausgeführt werden
- Man kann auf macOS entwickeln und testen und anschließend auf Linux-basierten Servern deployen
- Linking ist der Prozess, bei dem verschiedene Teile eines Computerprogramms zusammengeführt und Referenzen aufgelöst werden
- Statisches Linking erfolgt zur Build-Zeit, dynamisches Linking zur Laufzeit
- Statische Bibliotheken sind Sammlungen einzelner Objektdateien, dynamische Bibliotheken sind monolithisch
- Vor- und Nachteile von statischem Linking:
- Vorteile: kein Laufzeit-Overhead, nur benötigter Bibliothekscode wird eingebunden, keine separat installierten dynamischen Bibliotheken nötig, keine Laufzeitprobleme durch Versionsunterschiede
- Nachteile: kein Code-Sharing möglich (höherer Speicherverbrauch), keine Updates von Abhängigkeiten ohne Neubau des Programms, größere ausführbare Dateien
- Mit statischem Linking unter Linux lassen sich distributionsabhängige Systembibliotheks-Abhängigkeiten vollständig eliminieren
- Auf swift.org muss die Open-Source-Toolchain installiert werden (die mit Xcode gelieferte Toolchain kann nicht verwendet werden)
- Mit dem Befehl
swift sdk install kann das Static Linux SDK installiert werden
- Mit dem Befehl
swift build --swift-sdk x86_64-swift-linux-musl lässt sich ein x86-64-Linux-Binary bauen, mit swift build --swift-sdk aarch64-swift-linux-musl ein ARM64-Linux-Binary
- Swift-Pakete, die Foundation oder Swift NIO verwenden, funktionieren unverändert
- Pakete, die C-Bibliotheken verwenden, müssen so angepasst werden, dass sie statt Glibc Musl importieren
- Musl unterstützt statisches Linking gut und hat eine permissive Lizenz, die die Verteilung ausführbarer Dateien erleichtert
- Mit dem Befehl
swift package edit können Paketabhängigkeiten angepasst werden
2 Kommentare
Ich habe das Gefühl, dass sich damit wohl etwas umsetzen lässt, das die gleichzeitige Entwicklung für Android und iOS mit Swift nahtloser unterstützt …
Hacker-News-Kommentare
Neue Unterstützung für benutzerdefinierte Plattformen in Swift: Dass Swift Embedded-Systeme und WASM unterstützt und zu einer nicht von Apple geführten GitHub-Organisation gewechselt ist, ist ein großer Fortschritt für die Ausweitung von Swift auf andere Plattformen. Interessant ist auch die mögliche Nutzung für die Sicherheitsverifikation von AI-OS.
Swift-Binärdateien in Alpine-Containern ausführbar: Es ist erfreulich, dass Swift-Binärdateien nun in Alpine-Containern ausgeführt werden können. Die Arbeit an der musl-Unterstützung schreitet schneller voran als erwartet. Auch Cross-Compilation ist sehr nützlich.
Vorfreude auf Debian-Unterstützung: Es ist schön zu sehen, dass Swift-Pakete für Debian hinzukommen. Wahrscheinlich werde ich Debian häufiger als Entwicklungs-VM verwenden.
Vorfreude auf Swift in Embedded-Systemen: Ich habe viel mit Embedded-Systemen in C gearbeitet, würde Swift aber gern einmal auf einem STM-Development-Board ausprobieren.
Nachteile statischen Linkens: ASLR funktioniert entweder nicht richtig oder es wird nur ein einziges Objekt randomisiert. Bei speichersicheren Sprachen ist das vielleicht kein großer Nachteil. Das Teilen gemeinsamer Objekte kann zudem I/O verringern.
Kompatibilitätsprobleme zwischen Distributionen: Programme, die für eine bestimmte Distribution oder Version gebaut wurden, laufen möglicherweise nicht auf anderen Distributionen. Dass Swift statisches Linken anbietet, ist gut, aber am besten ist es, wenn Distributionen selbst entscheiden können, wie sie Pakete verteilen.
Potenzial zur Konkurrenz mit Golang: Swift könnte bei der einfachen Bereitstellung mit Golang konkurrieren. Dadurch wird die Komplexität weiter vom Endnutzer ferngehalten.
Cross-Plattform-GUI-Apps: Ich frage mich, wie es wäre, Cross-Plattform-GUI-Apps mit Swift zu bauen. SwiftUI dürfte wohl nicht nutzbar sein, aber ich plane, Swift für einfache Skripte zu verwenden.
Warnung vor der Nutzung von CentOS-7-Images: Dass noch immer CentOS-7-Images angeboten werden, wirkt verrückt. Eine klare Warnung, sie nicht zu verwenden.
Zunehmende Komplexität von Swift: Swift hätte Python leicht ersetzen können, aber die Sprache ist komplexer geworden und nun eine Art C++-Abklatsch.
Warum Swift statt Rust verwenden: Die Frage, warum man Swift statt Rust verwenden sollte.
Warum Swift ohne iOS/SwiftUI verwenden: Die Frage, ob es ohne iOS/SwiftUI überhaupt einen Grund gibt, Swift zu nutzen. Abgesehen davon, dass Swift-Entwickler bei kleinen Projekten eine vertraute Sprache verwenden möchten, scheint es kaum Gründe zu geben.