Swift ist das bequemere Rust

Rust

• Rust ist eine sehr beliebte Sprache, schnell und mit einer großartigen Community
• Rust löst Probleme der Speicherverwaltung durch die Einführung des Ownership-Konzepts
• Es bietet Utilities wie Rc, Arc und Cow, die Referenzzählung und "clone-on-write" unterstützen
• Wenn Low-Level-Arbeit nötig ist, kann man mit dem unsafe-System auf rohe C-Zeiger zugreifen
• Rust besitzt viele Merkmale funktionaler Sprachen wie getaggte Enumerationen, Match-Ausdrücke, First-Class-Funktionen und ein starkes Typsystem
• Mit einem LLVM-basierten Compiler kann Rust zu nativem Code und WASM kompiliert werden

Swift

• Auch Swift wurde über mehrere Jahre hinweg genutzt, und beim Lernen von Rust fielen die Ähnlichkeiten zu Swift auf
• Swift besitzt ebenfalls Merkmale funktionaler Sprachen wie getaggte Enumerationen, Match-Ausdrücke und First-Class-Funktionen
• Swift verwendet standardmäßig Werttypen und hat eine "copy-on-write"-Semantik
• Wenn mehr Performance nötig ist, kann man sich für ein Ownership-System entscheiden und Werte "move"n
• Wenn Low-Level-Arbeit nötig ist, kann man mit dem unsafe-System auf rohe C-Zeiger zugreifen
• Auch Swift verwendet einen LLVM-basierten Compiler und kann zu nativem Code und WASM kompiliert werden

Déjà-vu?

• Swift und Rust haben sehr ähnliche Feature-Sets
• Der große Unterschied liegt in der Perspektive
• Betrachtet man das zugrunde liegende Speichermodell, wird der Unterschied deutlich

Rust ist top-down, Swift bottom-up

• Rust beginnt als Low-Level-Systemsprache und stellt Werkzeuge bereit, um sich zu höheren Ebenen vorzuarbeiten
• Swift beginnt als High-Level-Sprache und stellt Werkzeuge bereit, um sich zu niedrigeren Ebenen hinunterzuarbeiten
• Das Modell der Speicherverwaltung ist das deutlichste Beispiel
• Swift verwendet standardmäßig Werttypen und hat eine "copy-on-write"-Semantik
• Rust macht den Umgang mit "moved" und "borrowed" Werten einfach, aber Cow-Werte erfordern zusätzlichen Aufwand
• Swift macht den Umgang mit "copy-on-write"-Werten einfach, dafür erfordern Borrowing und Moves zusätzlichen Aufwand
• Rust ist standardmäßig schneller, Swift standardmäßig einfacher und leichter

Swift versteckt Rust-Ideen hinter einer C-ähnlichen Syntax

• Die Syntax von Swift versteckt Konzepte funktionaler Sprachen hinter einer C-ähnlichen Syntax, sodass Entwickler sie leichter annehmen können
• Vergleich der match-Anweisung in Rust mit der switch-Anweisung in Swift
• Die switch-Anweisung in Swift ist tatsächlich identisch mit einem match-Ausdruck, hat aber einen anderen Namen und eine andere Syntax
• In Swift kann man Methoden direkt zu enum hinzufügen

Optionale Typen

• Rust hat kein null, aber None
• Swift hat nil, was aber tatsächlich dasselbe wie None ist
• Swift verwendet T? statt Option, und der Compiler erzwingt die Prüfung, dass ein Wert nicht nil ist
• In Swift lassen sich optionale Typen einfach verwenden

Fehlerbehandlung

• Rust hat kein try-catch, sondern verwendet den Typ Result
• Swift verwendet statt try-catch do-catch, und vor Funktionsaufrufen muss try stehen
• Die Fehlerbehandlung in Swift ähnelt der in Rust, ist aber hinter vertrauterer Syntax verborgen

Der Compiler von Rust fängt Probleme ab, der Compiler von Swift löst einige Probleme

• Der Compiler von Rust erkennt viele häufige Probleme schon zur Compile-Zeit und schlägt Lösungen vor
• Beispiel für selbstreferenzielle Enumerationen
• Swift markiert rekursive Typen mit dem Schlüsselwort indirect, und der Compiler übernimmt den Rest

Swift ist weniger "rein"

• Swift wurde als Ersatz für Objective-C entworfen und musste mit bestehendem Code zusammenarbeiten können
• Swift hat viele pragmatische Entscheidungen getroffen und ist eine größere Sprache als Rust
• Swift wurde mit dem Gedanken an "progressive disclosure" entworfen, sodass mit zunehmendem Lernen der Sprache mehr Features sichtbar werden
• Einige Sprachfeatures von Swift:
  • Klassen / Vererbung
  • async-await
  • async-sequences
  • actors
  • Getter und Setter
  • lazy properties
  • property wrappers
  • Result Builders (z. B. HTML / SwiftUI)

Der Preis der Bequemlichkeit

• Swift ist eine Sprache, mit der man leichter anfangen und schneller produktiv werden kann
• Die Syntax ist vertrauter, und vieles wird automatisch erledigt
• Swift ist eine stärker auf höherer Ebene angesiedelte Sprache, mit denselben Trade-offs
• Standardmäßig sind Rust-Programme deutlich schneller als Swift-Programme
• Rust ist standardmäßig schnell und lässt einen langsam machen, Swift ist standardmäßig einfach und lässt einen schnell machen
• Beide Sprachen haben jeweils ihren Einsatzzweck
  • Rust eignet sich besser für System- und Embedded-Programmierung
  • Swift eignet sich besser für UI- und Server-Entwicklung
• Mit der Zeit wird die Überschneidung zwischen beiden Sprachen voraussichtlich größer werden

Zusammenfassung von GN⁺

• Dieser Artikel erklärt im Vergleich die Ähnlichkeiten und Unterschiede zwischen Swift und Rust
• Swift übernimmt viele Ideen aus Rust und bietet sie in vertrauterer Syntax an
• Beide Sprachen haben jeweils ihre Stärken und Einsatzbereiche, und mit der Zeit dürfte es mehr Überschneidungen geben
• Er hilft dabei, Unterschiede bei Speicherverwaltung, Fehlerbehandlung und optionalen Typen zwischen Swift und Rust zu verstehen
• Sprachen mit ähnlichen Features sind unter anderem Kotlin und TypeScript

[GN⁺]

Hacker-News-Kommentare

• Der Grund, warum Leute, die Rust zum ersten Mal benutzen, Rust mögen, ist, dass sie zum ersten Mal mit Sprachen aus der ML-Familie in Berührung kommen

  • Rust bietet eine Community, die Unix-Hackern vertraut ist

• Rust ist die erste Sprache, die automatische Speicherverwaltung ohne GC in den Mainstream gebracht hat

  • Es gibt auch Alternativen wie Swift, OCaml und Scala

• Die Ära von Smalltalk ist vorbei, jetzt ist die Zeit von ML

  • Die Sprachen der 2000er leiten sich von Smalltalk ab
  • Neue Sprachen gehören zur ML-Familie
  • Wenn man Scala lernt, kann man auch Rust oder Swift leicht lernen

• Bei der Arbeit an der Integration von Rust in eine iOS-Swift-App wollte ich Swift stärker nutzen

  • Swift kann plattformübergreifend verwendet werden, zielt aber hauptsächlich auf Apple-Plattformen ab
  • Rust hat verschiedene Paketsysteme
  • Swift-Pakete hängen oft von OS-APIs ab und funktionieren daher nicht unter Linux oder WASM
  • Es gab den Fall, dass IBM Swift auf dem Server aufgegeben hat

• Rust hat das Konzept des Ownership eingeführt, um Probleme der Speicherverwaltung zu lösen, hat es aber nicht erfunden

  • Sprachen wie Cyclone hatten darauf Einfluss

• Rust und Swift haben jeweils ihre eigenen Stärken

  • Swift hat eine knappere Syntax, aber einige Bereiche sind Compiler-exklusiv
  • Außerhalb des Apple-Ökosystems ist Swift nur die zweit- oder drittwichtigste Sprache
  • Wenn dieses Problem nicht gelöst wird, wird Swift überwiegend eine Apple-spezifische Sprache bleiben

• Die Werkzeuge von Swift sind unbequemer als die von Rust

  • Xcode wird auf einem MacBook Air von 2018 mit macOS 12 nicht unterstützt
  • SourceKit-LSP wird wie ein zweitrangiges Werkzeug behandelt
  • Rust 1.81 und rust-analyzer funktionieren gut

• Ich habe versucht, Rust zu lernen, hatte aber Schwierigkeiten, weil die Beispiele zu kompliziert waren

  • Der Beispielcode auf der Rust-Website ist komplex

• In Swift kann man Methoden direkt zu Enums hinzufügen

  • Das Gleiche geht auch in Rust

• Swift verwendet standardmäßig Value Types und Copy-on-Write-Semantik

  • Das gilt nur für Arrays, Dictionaries und Strings
  • Swift-Value-Types werden sofort kopiert

• Immer wenn ich Texte lese, die Swift loben, frage ich mich, wie die Erfahrung von Entwicklern ist, die nicht im Apple/MacOS-Ökosystem arbeiten

  • Ich habe noch nie einen Swift-Entwickler getroffen, der kein macOS benutzt
  • Wichtig sind nicht nur die Standardbibliothek, sondern auch Tools, LSP, Bibliotheken, Tutorials usw.
  • Ich glaube, dass Swift eine gute Sprache ist, aber anscheinend nur unter macOS

• Ich frage mich, ob ich der Einzige bin, der die Punkt-Syntax von Zig und Swift nicht mag

  • .variant vs Type::Variant
  • In ausreichend langem oder komplexem Code ist es unpraktisch, wenn der Typname nicht in der Nähe steht
  • Das gilt besonders in Editoren ohne IDE-ähnliche Funktionen