Rust Details

Notizen zu Rust.

Code-Stabilität ohne Stagnation

Rust – die Sprache, der Compiler rustc, sowie die Standardbibliothek – werden ständig weiterentwickelt. In Rust geschriebener Code soll dabei stets mit zukünftigen Versionen von Rust fehlerfrei kompilieren. Brüche erfolgen nur innerhalb einer jeweils neuen, vom Entwickler auswählbaren Edition.

Eigenschaften vergangener und zukünftiger Rust-Versionen werden in releases.rs aufgelistet.

Zero-Overhead Abstractions

Ein Ziel von Rust sind „Zero-Overhead Abstractions”. Damit sind Abstraktionen gemeint, die ohne vermeidbare Laufzeitkosten auskommen. Das bedeutet:

1. Die Kosten fallen nur an, falls die Abstraktionen gewollt verwendet werden.
2. Die Kosten sind in dem Fall auch nicht größer, als wenn die Abstraktionen selbst implementiert werden würden.

Gelegentlich wird dies auch mit „Zero-Cost” bezeichnet, was aber zu dem Missverständnis führen kann, dass durch die Abstraktionen überhaupt keine Laufzeitkosten entstehen.

Beispiele für Zero-Overhead Abstraktionen in Rust:

• Allokation: der Entwickler kann steuern, ob Allokation auf dem Heap oder dem Stack erfolgt
• Dispatch: der Entwickler kann steuern, ob Dynamic Dispatch oder Static Dispatch verwendet wird.
• Es gibt keine unvermeidbare Laufzeitumgebungen für:
  • Garbage Collection: die Buchhaltung des Speichers erfolgt grundsätzlich zur Kompilierzeit.
  • Green Threads: falls gewünscht, können Laufzeitumgebungen von optionalen Crates gewählt werden.

Minimale Standard Library

Dass Rust nur eine minimale Standard Library anbietet, war eine bewusste Entscheidung. Cargo ermöglicht es aber, eigene Libraries und Libraries anderer Entwickler („Crates”) effizient zu nutzen.

Chancen:

• Es ist möglich, Crates zu entwickeln, ohne die Garantien der Standard Library einhalten zu müssen, dass nutzender Code auch in Zukunft kompilieren und funktionieren wird.
• Es ist möglich, konkurrierende Ansätze zu implementieren und zu vergleichen.
• Es ist möglich, Crates zu entwickeln, ohne alle von Rust unterstützte. Plattformen abdecken zu müssen.

Risiken:

• Geeignete Crates können nicht immer einfach gefunden und bewertet werden.
• Neben den Rust-Entwicklern muss weiteren Entwicklern vertraut werden.
• Fragmentierung des Ökosystems, z.B. bei asynchronen Runtimes (smol, Tokio)

Beispiele für nicht optimalen Code in Standard Libraries:

• C:
  • rand(): TODO
• Go:
  • net/http: TODO Projekte wie grpc-go verwenden eigene HTTP/2-Implementierungen.
• Java:
  • Die Date/Time-API (java.util.Calendar, java.util.Date) war bis Java 8 jahrelang in einem unbefriedigenden Zustand.
• PHP:
  • Funktionen und Methoden sind inkonsistent benannt.
• Python (siehe auch PEP 594):
  • Funktionen und Methoden sind inkonsistent benannt.
  • asyncio: TODO curio, trio
  • http.server: TODO
  • subprocess: TODO
  • urllib, urllib2: TODO
• Rust:
  • std::sync::mpsc: die API hat sich über die Jahre als nicht optimal herausgestellt. Die Implementierung wurde durch das unabhängig entwickelte crossbeam-channel ersetzt.

Beispiele verbreiteter Libraries, die nicht Teil einer Standard Library sind:

• C++:
  • boost
• Java:
  • log4j
  • Spring
• Python:
  • Django
  • Flask
  • Requests
• Rust:
  • lazy_static vs once-cell
  • rustc_serialize vs Serde

Traits

Datentypen können mittels Traits gruppiert werden. Traits können Methoden sowohl deklarieren, als auch default-implementieren. Daten-Member können in Traits jedoch nicht definiert werden.

Implementierung

Traits werden für einen Datentyp entweder in einfachen Fällen automatisch mittels derive oder manuell mittels impl Trait for Datentyp { ... } implementiert.

Trait-Deklarationen und -Implementierungen können sich in unterschiedlichen Crates befinden. Die Orphan Rule verbietet jedoch, dass ein Trait aus einem externen Crate für einen Datentyp aus einem externen Crate implementiert wird. Dadurch wird sichergestellt, dass es für jede Kombination aus Datentyp und Trait unmissverständlich nur eine einzige Implementierung gibt.

Auto Traits werden mit dem Keyword auto markiert. Falls er es für angebracht hält, implementiert der Compiler diese Traits für Datentypen automatisch. Beispiele sind std::marker::Send und std::marker::Sync.

TODO: Blanket Implementations

Verwendung

Um eine Trait-Methode für einen Datentyp aufrufen zu können, muss neben dem Datentyp auch der Trait importiert werden.

Methoden können auch als freistehende Funktion aufgerufen werden. Ist z.B. die Methode A::f(&self, b: B) implementiert, so kann sie für eine Instanz a von A nicht nur als a.f(b), sondern auch als A::f(a, b) verwendet werden.

Polymorphismus

Statischer Polymorphismus

Von statischem Polymorphismus spricht man, falls Trait-Methoden aufgerufen werden und der Datentyp zur Kompilierzeit bekannt ist: impl Trait.

Einschränkungen:

• Trait-Methoden können derzeit nicht den Return-Wert impl Trait haben.

Dynamischer Polymorphismus

Von dynamischen Polymorphismus spricht man, falls Trait-Methoden aufgerufen werden und der Datentyp zur Kompilierzeit nicht bekannt ist: dyn Trait.

Da die Größe des Datentyps, der dyn Trait erfüllt, zur Kompilierzeit nicht bekannt ist (!Sized, siehe Abschnitt „Marker Traits”), kann dyn Trait alleine nicht genutzt werden. Vielmehr muss dyn Trait in einen Wide Pointer verpackt werden (z.B. &dyn Trait, Box<dyn Trait>, Arc<dyn Trait> etc.). Ein solcher Wide Pointer wird „Trait Object” genannt und enthält neben der Adresse des Datentyps auch eine Virtual Table mit den Adressen der Methoden-Implementierungen.

Ein Trait Object ist möglich, falls der Trait „object safe” ist:

• keine Methode darf statisch sein
• keine Methode darf sich auf Self beziehen
• keine Methode darf generische Typ-Parameter verwenden

Upcasting von Traits eines Trait Objects ist seit Rust 1.86 möglich.

Einschränkungen:

• Clonen ist nicht möglich, da Clone nicht object safe ist. Als Workaround kann das Crate dyn-clone genutzt werden.

Polymorphismus bzgl. des Return-Wert-Typs

TODO

Inheritance

Traits können automatisch vereinigt werden: trait C: A+B {}.

Datenstrukturen, sowie die für sie implementierten Methoden, können nicht automatisiert vereinigt werden.

Trait Bounds

TODO Bei generischen Typ-Parametern, Funktionsargumenten und -Return-Werten, sowie bei Trait-Definitionen.

Mehrere Traits können nur dann als Trait Bound einer Closure oder eines Trait Objects verwendet werden, wenn sie Auto Traits sind.

Marker Traits

Marker Traits haben keine Methoden. Sie für einen Datentypen zu implementieren, bedeutet lediglich, den Compiler anzuweisen, diesen Datentyp besonders zu behandeln:

• Copy: Implementiert ein Datentyp Copy, so kann er durch den Compiler (bei Zuweisung oder Übergabe an eine Funktion) implizit dupliziert werden.
• Send: Implementiert ein Datentyp Send, so kann höchstens 1 Thread exklusiven Zugang haben.
• Sized:
  • Ein Datentyp implementiert genau dann Sized, falls er eine zur Kompilierzeit bekannte, endliche Größe hat. Nur solche Datentypen können auf dem Stack abgelegt werden. Für alle anderen Datentypen können nur Pointer auf sie auf dem Stack abgelegt werden.
  • Alle Typ-Parameter sind Sized, nicht jedoch bei Self in Traits, weil es Trait Objects verhindert.
    • Diese Einschränkung kann mit ?Sized entfernt werden.
  • Generics durchlaufen Monomorphization/Reification, daher muss Self: Sized sein. TODO
• Sync: Implementiert ein Datentyp Sync, so können mehrere Threads gleichzeitig geteilten Zugang haben. Erfüllt ein Datentyp weder Send noch Sync, dann ist Zugang auf seine Instanz nur aus dem Thread möglich, aus dem die Instanz stammt.
• Unpin: TODO

Der Compiler validiert ggf. rekursiv, dass alle Bestandteile des Datentyps den Trait bzw. die Trait Bounds erfüllen.

Ownership-Modell

Der kleinste Codebereich, in dem ein Datentyp instantiiert wird, ist der Besitzer (Owner) dieser Instanz. Nur der Besitzer hat auf sie Zugriff.

Der Besitz (Ownership) kann durch einen Move auf andere Codebereiche übergehen:

• durch Bindung an Variablen (mittels Gleichheitszeichen oder Pattern Matching)
• durch Übergabe als Argument an eine Funktion
• durch Übergabe eines Return-Werts einer Funktion oder eines Blocks an den Aufrufer

Zu jedem Zeitpunkt gibt es höchstens einen Besitzer. Der Compiler stellt sicher, dass Bindungen des vorherigen Besitzers nach einer Übertragung nicht mehr verwendet werden können.

Sobald Daten den besitzenden Codebereich verlassen, ohne dass sie von einem anderen Codebereich übernommen wurden, sind sie ungenutzt und ihr Speicherplatz kann und wird durch den Compiler freigegeben. Dies gilt auch für Freigabe anderer Ressourcen, wie geöffnete Dateien, Netzwerkverbindungen oder Locks.

Da immer höchstens ein Codebereich vollen Zugriff hat, sind Fehler aufgrund gleichzeitigen Zugriffs ausgeschlossen.

Clone, Copy

Die Besitzübertragung mittels Move ist außer bei primitiven Datentypen die Regel. Daten können vor der Übergabe dupliziert (geklont) werden, womit nur das Duplikat den Besitzer wechselt. Eine weitere Möglichkeit die Abgabe des Besitzes zu vermeiden ist das Borrowing (siehe nächster Abschnitt).

Die Duplizierung erfolgt über den Aufruf der Methode clone(), falls für den Datentyp der Trait Clone implementiert ist.

Ist für den Datentyp hingegen der Marker Trait Copy implementiert, erfolgt die Duplizierung an den entsprechenden Stellen durch den Compiler implizit. Ein expliziter Aufruf von clone() ist dann unnötig. rust-clippy weißt auf unnötigen Aufrufe von clone() hin.

Der Compiler implementiert Copy mittels bitweisem Kopieren. Bei Datentypen, wie String bzw. Vec, welche Pointer auf Bereiche im Heap halten, ist ein bitweises Kopieren unzulässig, da die duplizierten Pointer zu Speicherfehlern führen würden.

Borrowing, Lifetimes

Mittels Borrowing kann anderen Codebereichen temporärer Zugriff auf Daten gewährt (ausgeliehen) werden, ohne dass der Besitz abgegeben werden muss.

Referenzen erlauben Zugriff auf zwei Arten:

• &T: gewährt geteilten Zugriff
• &mut T: gewährt exklusiven Zugriff

Eine Lifetime gibt an, wie lange eine Referenz eines bestimmten Speicherbereichs gültig ist. Sie endet spätestens mit dem Drop der Daten, aber auch bereits mit einem Move.

Der Borrow Checker des Compilers stellt dies sicher. Kann er nicht eindeutig erkennen, dass die Lifetimes eingehalten werden, lehnt er den Code im Zweifel ab. Ein fälschliches Akzeptieren von Code würde dessen Speichersicherheit gefährden.

Copy vs Borrowing

Die Entscheidung zwischen Copy und Borrowing ist nicht immer trivial.

Typen von Parametern und Return-Werten

TODO:

• std::convert::AsRef: TODO z.B. AsRef<Path>.
• std::convert::From: TODO
• std::convert::Into: TODO
• std::ops::Deref: TODO
• std::borrow::Borrow: TODO
• std::borrow::Cow: TODO std::borrow::ToOwned ist die Umkehrfunktion.

Asynchronous Rust

TODO Informed polling, cooperative scheduling.

• Initialisierung: async-Funktionen und -Blöcke werden in eine State Machine gewrappt. Der Returnwert-Typ ist nicht T, sondern impl Future<Output=T> + '_.
• Verwendung: die externe Runtime arbeitet die State Machine ab.

Der Compiler kann nicht überprüfen:

• ob der Executor zur Laufzeit nicht ungewollt blockiert wird
• dass die Funktion aufgrund eines vergessenen .await nicht ausgeführt wird

Wenn async Funktionen rekursiv aufgerufen werden sollen, muss der Result-Typ geboxed werden. Andernfalls hätte der Return-Wert-Typ — ähnlich wie bei rekursiven Enums oder Structs — unendliche Größe:

• mit Send Bound: BoxFuture, zusammen mit FutureExt::boxed()
• ohne Send Bound: LocalBoxFuture, zusammen mit FutureExt::boxed_local()

Einschränkungen

• Trait-Methoden können derzeit nicht async sein.
  • Insbesondere ist async Drop noch nicht möglich.
  • Als Workaround kann das Crate async-trait verwendet werden.
    • Den Send Trait Bound kann man verhindern durch #[async_trait(?Send)] bei Deklaration und Implementation.

Explizites vs. Implizites

Explizites

• Konstruktoren:
  • Jede Funktion oder Methode, welche Instanzen eines Datentyps erzeugt und liefert, ist ein Konstruktor. Namen wie new(), from_X(), with_X() sind lediglich Konvention.
  • Ein Datentyp hat den Default-Konstruktor default(), falls der Trait Default für diesen Datentypen implementiert ist.
• Destruktoren:
  • Ein Datentyp hat den Destruktor drop(), falls für den Datentyp der Trait Drop implementiert ist.

Implizites

• async:
  • Initialisierung: async-Funktionen und -Blöcke werden in eine State Machine gewrappt. Der Returnwert-Typ ist nicht T, sondern impl Future<Output=T> + '_.
  • Verwendung: die externe Runtime arbeitet die State Machine ab.
• Auto Borrowing: TODO
• Auto Traits: Traits, die automatisch für Datentypen definiert sind.
• Closures:
  • Initialisierung: ein anonymer Struct wird erzeugt, welcher entweder die gecapturten Werten enthält (falls mit move) oder Referenzen auf diese (falls ohne move).
  • Verwendung: eine Methode eines der folgenden Traits wird aufgerufen: Fn, FnMut oder FnOnce aufgerufen.
• Coercion: Datentypen können implizit in andere umgewandelt werden.
• Copy-Semantik: TODO
• Deref-Coercion: deref() aus dem Trait Deref wird vom Compiler implizit aufgerufen.
• Destruktoren:
  • Initialisierung: Drop-Glue wird erzeugt.
  • Der Destruktor drop() wird implizit aufgerufen, sobald der Wert out-of-scope geht.
• for-Schleifen: rufen implizit die Methode into_iter() des Traits std::iter::IntoIterator auf.
• Lifetime Elision: die Lifetime wird implizit bestimmt und muss nicht definiert werden.
• Marker: Strukturen oder Traits, die alleine durch ihre Verwendung, die Behandlung von Datentypen durch den Compiler verändern.
• Method Resolution: TODO
• Move-Semantik: TODO
• Operatoren: TODO
• Panic: TODO
• Prelude: Definitionen, die automatisch im Scope sind
• Reborrow: TODO
• Thread locals: TODO

Den Compiler nutzen

Mit bestimmtem Code kann der Compiler dazu genutzt werden, Eigenschaften von Datentypen entweder zu bestätigen oder mittels Fehlermeldungen zu erklären.

Erklären lassen:

• den Datentyp von a:
  • let _: () = a;

Bestätigen:

• die Object Safety des Traits T:
  • fn assert_object_safety(a: Box<dyn T>) {}
• die Thread-Sicherheit des Datentyps A:
  • fn assert_send<T: Send>() {}; assert_send::<A>();
  • fn assert_sync<T: Sync>() {}; assert_sync::<A>();
• die Lifetime des Datentyps A:
  • fn assert_contravariance<'a>(a: A<'l>) -> A<'static> { a }
  • fn assert_covariance<'a>(a: A<'static>) -> A<'l> { a }

Smart Pointer

Smart Pointer erlauben, Einschränkungen des Borrow Checkers zu umgehen.

nicht thread-safe

„Nicht thread-safe“ bedeutet, dass der Code nicht kompilieren würde, falls versucht wird, nicht thread-safe Datenstrukturen zwischen Threads auszutauschen.

• im Modul std::cell:
  • für interior Mutability (Veränderung via Referenzen & anstatt unique Referenzen &mut):
    • falls etwa logisch immutable ist, technisch aber Mutation erfordert:
      • Caching
      • Zähler hochsetzen, z.B. in clone()
      • die Signatur einer Trait-Methode erlaubt keine Mutation
  • Cell:
    • gibt keine Referenzen heraus, der Wert wird beim Schreiben und Lesen kopiert
      • => eher für kleine Datentypen
    • verwendet intern UnsafeCell
  • RefCell:
    • gibt nur unique Referenzen heraus
    • verwendet intern UnsafeCell
• im Modul std::rc:
  • Reference Counting
  • Rc:
    • gibt nur unique Referenzen heraus
  • Weak:
    • TODO

thread-safe

• im Modul std::sync:
  • TODO

Kombinationen

• Arc<Mutex<T>>: TODO
• Rc<RefCell<T>>: TODO

Einschränkungen

• Pattern-Matching ist für Box, Vec nicht möglich. Für Box gibt es das experimentelle Attribut #![feature(box_syntax, box_patterns)].

Macros

TODO

• cargo-expand

Tests

Unit Tests

TODO

• Code Coverage:
  • cargo-llvm-cov
  • nur unter Linux: cargo tarpaulin --ignore-tests

Fuzzer

TODO

optimieren

die Kompilierung beschleunigen

• Abhängigkeiten:
  • das eigene Projekt mittels Workspace/Crates und Features unterteilen
  • nicht benötigte Abhängigkeiten komplett entfernen:
    • eigene Abhängigkeiten:
      • cargo tree: erleichtert zu erkennen, falls ein Crate in verschiedenen Versionen gleichzeitig verwendet wird.
      • cargo-udeps: findet unbenutzte eigene Abhängigkeiten
    • Es empfiehlt sich, die eigenen Abhängigkeiten zu aktualisieren, da diese wiederum ihre Abhängigkeiten optimiert haben könnten:
      • cargo update
      • cargo outdated: findet neuere Versionen der eigenen Abhängigkeiten
  • nicht benötigte Features von Abhängigkeiten nicht kompilieren
  • Abhängigkeiten durch schlankere Altrnativen ersetzen:
    • cargo-bloat: cargo bloat --time --release -j 1
• cargo check verwenden statt cargo build
• in Cargo.toml im Abschnitt [profile.dev] definieren:
  • split-debuginfo = \"unpacked\": TODO
• schnelleren Linker verwenden:
  • lld
  • mold

das Kompilat performanter und kleiner machen

• in Cargo.toml im Abschnitt [profile.release] definieren:
  • codegen-units = 1: TODO
  • lto = \"fat\": TODO
  • -C target-cpu=native: TODO
  • panic = \"abort\": TODO
  • strip=\"symbols\": TODO
• Benchmarken:
  • cargo bench: TODO
  • criterion: TODO
  • hyperfine: TODO

sicherer machen

• die direkt und indirekt verwendeten Crates überprüfen:
  • nach Sicherheitslücken:
    • cargo-audit
    • cargo-crev
    • Deps.dev
  • nach ungewünschten Lizenzen:
    • cargo-deny
  • nach Benutzung von unsafe:..
    • cargo-geiger