Swift ist das bequemere Rust (2023)

 (nmn.sh)
2 Punkte von GN⁺ 2026-02-01 | 1 Kommentare | Auf WhatsApp teilen
  • Rust und Swift teilen sich beide ein starkes Typsystem und Eigenschaften funktionaler Sprachen und können dank LLVM-basierten Compilern zu nativem Code und WASM kompiliert werden
  • Rust begann als Systemsprache auf niedriger Ebene und bietet Funktionen auf höherer Ebene, während Swift als Sprache auf höherer Ebene begann und Zugriff auf niedrigere Ebenen erlaubt
  • Swift nutzt standardmäßig Werttypen und Copy-on-Write und setzt ähnliche Konzepte wie das Ownership-Modell von Rust mit einfacherer Syntax um
  • Bei optionalen Typen, Fehlerbehandlung und rekursiven Enums verpackt Swift Konzepte aus Rust in eine C-ähnlich vertraute Syntax und bietet Entwicklern dadurch mehr Komfort
  • Swift entwickelt sich zu einer plattformübergreifenden Sprache weiter und kann auch unter Windows, Linux und in Embedded-Umgebungen eingesetzt werden, wodurch es sich als Alternative zu Rust etabliert

Gemeinsamkeiten und Unterschiede zwischen Rust und Swift

  • Beide Sprachen enthalten Eigenschaften funktionaler Sprachen (tagged Enums, match/switch-Ausdrücke, Generics, First-Class Functions)
    • Rust bietet mit Rc, Arc, Cow Referenzzählung und Kontrolle über Kopien
    • Swift verwendet standardmäßig Werttypen und Copy-on-Write und unterstützt bei Bedarf Ownership-Transfer (move) und unsafe Pointer-Zugriff
  • Beide Sprachen verwenden LLVM-basierte Compiler und können zu nativem Code und WASM kompiliert werden

Speichermodell: Rust top-down, Swift bottom-up

  • Rust begann als Systemsprache auf niedriger Ebene und bietet Funktionen auf höherer Ebene
  • Swift begann als Sprache auf höherer Ebene und erlaubt bei Bedarf Zugriff auf niedriger Ebene
  • Das Standard-Speichermodell von Swift sind Copy-on-Write-Werttypen, ähnlich zu Rusts Cow<>
    • Rust ist standardmäßig schnell, verlangt aber, dass Cow<> explizit behandelt wird
    • Swift ist standardmäßig einfach, kann aber statt Kopieren auch Verschieben wählen

Swifts syntaktischer Ansatz: Rust-Konzepte im C-Stil verborgen

  • Swifts switch-Anweisung erfüllt praktisch dieselbe Funktion wie der match-Ausdruck in Rust
    • Sie unterstützt Pattern Matching und hat kein fallthrough
  • Swifts enum kann direkt Methoden enthalten, wodurch es objektorientierter genutzt werden kann als in Rust
  • Optionale Typen (T?) entsprechen konzeptionell Rusts Option<T>, und nil entspricht None
    • In Swift kann per if let val sicher entpackt werden
  • Die Fehlerbehandlung ähnelt Rusts Result-Typ, und Swifts do-catch und try sind dieselbe Struktur in vertrauter Syntax verpackt

Unterschiede im Compiler-Verhalten

  • Der Rust-Compiler legt den Schwerpunkt auf Problemerkennung und Warnungen und erzwingt zum Beispiel bei der Definition eines rekursiven Enums die Verwendung von Box<>
  • Swift verarbeitet rekursive Enums allein mit dem Schlüsselwort indirect, wobei der Compiler die interne Pointer-Verwaltung automatisch übernimmt
  • Swift automatisiert im Vergleich zu Rust mehr Verarbeitungsschritte, sodass Entwickler seltener selbst mit Speicherstrukturen umgehen müssen

Swifts Praxistauglichkeit und Erweiterbarkeit der Sprache

  • Swift wurde als Ersatz für Objective-C entworfen und ist deshalb eine größere und praktischere Sprache
    • Klassen/Vererbung, async-await, actors, lazy Properties, property wrappers, Result Builders und viele weitere Funktionen sind eingebaut
  • Das Design der „progressive disclosure“ sorgt dafür, dass mit fortschreitendem Lernen nach und nach mehr Funktionen sichtbar werden

Balance zwischen Komfort und Leistung

  • Swift ist eine Sprache mit leichtem Einstieg und hoher Produktivität, Rust eine von Haus aus schnelle Sprache
    • Bei Rust gilt: „Schnelligkeit ist Standard“, bei Swift: „Komfort ist Standard“
  • Rust eignet sich für Systeme, Embedded, Compiler und Browser-Engines
  • Swift eignet sich für UI, Server und einige Komponenten von Betriebssystemen, und die Einsatzgebiete beider Sprachen überschneiden sich zunehmend

Swifts plattformübergreifende Expansion

  • Swift ist nicht länger eine reine Apple-Sprache
    • Windows: The Browser Company nutzt es für gemeinsamen Code im Arc-Browser
    • Linux: Apple unterstützt Swift on Server und sponsert Konferenzen
    • Embedded Swift: Einsatz auf kleinen Geräten wie dem Panic Playdate
  • Der offizielle Swift-Blog stellt Projekte für Windows, Embedded, Linux (Gnome) und Playdate vor
  • Mit einer VSCode-Erweiterung, Open-Sourcing des LSP und mehr verbessert Swift die Entwicklererfahrung auch außerhalb von Xcode

Grenzen von Swift und seine aktuelle Position

  • Die Kompilierzeit ist wie bei Rust langsam
  • Durch feature creep ist die Sprache größer geworden, und einige Syntaxelemente wirken ungewohnt
  • Das Paket-Ökosystem ist weniger ausgereift als bei Rust
  • Dennoch ist Swift bereits eine plattformübergreifende Sprache mit ABI-Stabilität, Automatic Reference Counting (ARC), wählbaren Ownership-Funktionen und Linux-kompatiblen Paketen
  • Swift etabliert sich als bequemere Alternative zu Rust und ist keine Zukunftsoption, auf die man noch warten muss, sondern eine Wahl für die Gegenwart

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-01
Hacker-News-Kommentare

  • Stimme größtenteils zu, aber in den Details zeigt sich der Kern des Problems
    Xcode ist bei großen Projekten eine raue IDE, die beim Aktualisieren von Paketen oder beim Umgang mit mehreren Targets oft hängen bleibt. Selbst wenn man es beheben möchte, sind Binary-Patches nicht möglich
    Das Build-System mit Cargo ist deutlich einfacher zu handhaben als SPM. Das Makro-System ist weiterhin auf externe Codegenerierung angewiesen
    Es gibt zwar Linter und Formatter, aber ihre Qualität ist niedrig. Swift hat viele Performance-Klippen, und die bidirektionale Typinferenz wird bei komplexen Ausdrücken langsam. Das ist besonders bei wichtigen Anwendungsfällen wie SwiftUI problematisch
    Imports sind auf Modulebene gebündelt, sodass schon bei einer Änderung an nur einer Datei das gesamte Modul neu kompiliert werden muss. Auch die Unterscheidung zwischen Klassen und Strukturen wirkt wegen der ObjC-Kompatibilität ungeschickt
    Am Ende könnte Swift zwar eine einfachere Sprache als Rust sein, aber wegen der Unausgereiftheit des Toolings fühlt es sich in der Praxis nicht so an

    • Ich habe eine kleine SwiftUI-App gebaut, und es war extrem schwer, ein Memory Leak zu finden. Selbst mit Instruments und vmmap liefen jeden Tag Dutzende MB aus
      Das halbautomatische Speichermodell von Swift fühlt sich viel schwerer beherrschbar an als das von Rust oder Go
    • Wenn man keine iOS-/macOS-App baut, kann man Xcode komplett überspringen und nur die swift-CLI verwenden. Das funktioniert auch unter Linux und Windows ziemlich gut
    • Swift unterstützt LSP, daher kann man auch in VSCode, Zed, Sublime Text usw. entwickeln. Für nicht Apple-spezifische Entwicklung ist Xcode nicht zwingend nötig
    • In älteren Swift-Versionen konnten ein oder zwei Zeilen mit Dictionary-Literalen dazu führen, dass ein Build 30 Minuten dauerte
    • Die meisten Probleme mit der Kompiliergeschwindigkeit lassen sich durch Trennung auf Paketebene und explizite Typangaben abmildern. SPM funktioniert besser als man denkt

  • Es hieß, dass man in Rust Box braucht, um Baumstrukturen mit Enums darzustellen, aber tatsächlich ist das unnötig, weil Vec bereits Heap-Referenzen bereitstellt

    • Ich kenne Rust gut, daher stört mich der Fehler selbst nicht, aber ich frage mich, ob die Erklärungen zu Swift ähnlich falsch waren
      Enums, Structs, Unions und sogar primitive Typen in Rust können alle Methoden haben. Zum Beispiel sind Aufrufe wie 'F'.to_digit(16) möglich
      Man kann sogar Raw Pointer mit Methoden versehen. Genau das halte ich für ein modernes Designelement von Rust
    • Am Beispiel von Swifts Enums zu sagen, der syntaktische Zucker sei gut, greift zu kurz, denn tatsächlich ist die Unterstützung für Union-Typen schwach, weshalb viele Entwickler statt Enums Optionals missbrauchen
    • Es ist leicht, den Unterschied zwischen Vec und Box zu verwechseln. Vec ist ein Handle mit zur Compile-Zeit fester Größe, Box wird gebraucht, wenn man mit unsized Typen arbeitet
    • Mit Rust 1.92 getestet, und es funktioniert auch ohne Box problemlos
    • Vec<T> selbst ist ein Handle fester Größe, das auf Heap-Daten zeigt, daher ist kein Box nötig

  • Swift ist eine coole Sprache, aber auf der Server-Seite wenig überzeugend
    Das Ökosystem ist klein, und gegenüber Go oder Rust gewinnt man kaum etwas. Die VSCode-Unterstützung ist schwach, und Xcode möchte ich nicht benutzen
    Server-Entwicklung wird bereits von Python, TypeScript, Go und Rust dominiert. Auch Apples geschlossenes Ökosystem ist eine Belastung

    • Ich habe tatsächlich schon ein Backend in Swift gebaut, mit direkter Anbindung an C-Bibliotheken. Es funktionierte auch ohne FFI gut und die Performance war ebenfalls gut
      Die IDE-Qualität ist besser als in anderen Sprachen, und für Systemprogrammierung halte ich Rust dennoch für geeigneter
    • Ich habe ein privates Projekt mit Swift Vapor gemacht, war aber enttäuscht, dass Kompilier- und Testgeschwindigkeit langsamer waren als bei Go

  • Swift gilt inzwischen als Cross-Platform-Sprache, aber unter Linux ist das Ökosystem immer noch stark auf Apple ausgerichtet
    Dokumentation, Tutorials und Bibliotheken sind alle auf macOS ausgerichtet. Ich frage mich, ob überhaupt jemand Swift ohne Apple-Geräte nutzt

    • In Apples Dokumentation sind die Einschränkungen unter Linux nicht klar angegeben, was zu viel Trial-and-Error geführt hat
      Ich habe meine Erfahrungen beim Bau eines WebSocket-Clients in einem Blog zusammengefasst
      Version von 2023 / Version von 2025
    • Apple-Entwickler sagen zwar, es sei auch unter Linux gut, aber in der Praxis ist das Rust-Ökosystem deutlich besser
    • Ich wollte ein CLI-Tool für den Mac nach Linux portieren, aber es war schneller und einfacher, den Code mit einem LLM nach Go umzuwandeln
      Android-Unterstützung ist zwar interessant, aber Kotlin reicht dafür meiner Meinung nach aus
    • Weil es so viele Apple-zentrierte Beispiele gibt, entstehen beim Cross-Compiling Probleme. Zum Beispiel existiert NSHashTable auf anderen Plattformen als Apple nicht
    • Mit dem swiftly-Tool, ähnlich wie rustup, kann man in Swift Compiler-Versionen verwalten, und auch LSP funktioniert gut
      Ich pflege persönlich Bibliotheken mit Unterstützung bis hin zu Windows. Es ist nicht perfekt, aber es wird allmählich besser

  • Swifts switch ist faktisch ein match-Ausdruck. Die Syntax ist nur anders, aber es führt Pattern Matching aus

    • Aus Sicht von Sprachdesignern wirkt das wie eine Strategie, die bestehende switch-Syntax beizubehalten, um Verwirrung bei Entwicklern zu verringern
      Mit vertrauter Syntax wurde neue Bedeutung eingeführt, um einen schrittweisen Übergang zu fördern
      Dieser Ansatz führt zu einer interessanten Diskussion darüber, wie meinungsstark ein Sprachdesign sein sollte

  • Der Kern von Rust ist zero-cost abstraction. Swift folgt diesem Prinzip nicht
    Viele Funktionen in Rust wurden so entworfen, dass sie diese Regel einhalten, und das Ownership-Modell ist dafür ein typisches Beispiel

    • Das explizite Ownership-Modell von Rust verhindert Laufzeitfehler, die bei Swift in Actors oder Tasks auftreten können, schon zur Build-Zeit
      Es hat zwar eine Lernkurve, steigert aber die Entwicklungseffizienz
    • Swift unterstützt ebenfalls ein Ownership-Modell, setzt es aber nicht so strikt durch wie Rust

  • Es hieß, der Arc-Browser habe Swift für Windows verwendet, aber nach der Einstellung der Entwicklung wurden die entsprechenden Arbeiten wohl ebenfalls gestrichen

  • Ich bevorzuge Rust, weil es nicht von einem Großkonzern abhängig ist. Ich halte es für möglich, dass Apple Swift irgendwann aufgibt

    • Allerdings ist es eher unwahrscheinlich, dass Apple Swift aufgibt. Rust könnte wegen seiner stärkeren Abhängigkeit von der Community sogar riskanter sein
    • Ein Großteil von Apples Software ist in Swift geschrieben, daher gibt es keinen Grund, es aufzugeben
    • Go ist an Google gebunden und C# an Microsoft. Da Swift ebenfalls Open Source ist, finde ich es schwer, es mit derselben Logik zu kritisieren
    • Swift wurde zwar von Apple geschaffen, wird aber von der Open-Source-Community weitergetragen
      Das steht auch im Wikipedia-Artikel

  • Wenn man in Rust Reference Counting nutzt, bekommt man die Bequemlichkeit auch ohne einen Wechsel zu Swift
    Mit Rc lassen sich unveränderliche gemeinsame Referenzen und mit interior mutability Änderungen auf Basis von Laufzeitprüfungen umsetzen
    Rc-Dokumentation, Dokumentation zu interior mutability

    • In Single-Thread-Umgebungen nutzt man Rc, in Multi-Thread-Umgebungen Arc. Dank des Send-Traits wird Rc nicht versehentlich im falschen Thread verwendet
    • Der Nachteil ist allerdings, dass der Code zu ausführlich werden kann

  • Ich habe Linux-Analysetools und Compiler sowohl in Swift als auch in Rust gebaut
    In Swift ist Speicherverwaltung dank ARC bequem, Rust verlangt mehr Nachdenken, aber die Qualität des Toolings ist deutlich besser
    Clippy und die LSP-Unterstützung sind hervorragend, und Swift bringt viele Funktionen standardmäßig mit
    Weil die Rust-Community jedoch größer ist, findet man leichter Leute, und ich sehe auch in Swift Potenzial als Ersatz für C++