Rust

Notizen zu Rust.

Zero-Overhead Abstractions

Rust bietet „Zero-Overhead Abstractions” an, also Abstraktionen ohne vermeidbare Laufzeitkosten:

1. die Kosten fallen nur an, wenn der Entwickler die Abstraktionen explizit verwendet.
2. die Kosten sind nicht größer, als wenn der Entwickler die Abstraktionen selbst programmieren würde.

Leider wird hierfür auch das Attribut „Zero-Cost” verwendet, was zum Missverständnis führen kann, dass durch diese Abstraktionen überhaupt keine Laufzeitkosten entstehen.

Beispiele für „Zero-Overhead Abstractions” in Rust:

• Allokation: der Entwickler kann steuern, ob Heap Allokation oder Stack Allokation verwendet wird.
• Dispatch: der Entwickler kann steuern, ob Dynamic Dispatch oder Static Dispatch verwendet wird.
• Es gibt keine erzwungene Bindung an Laufzeitumgebungen für:
• Garbage Collection: die Buchhaltung des Speichers erfolgt grundsätzlich zur Kompilierzeit.
• Green Threads: solche Laufzeitumgebungen sind in optionalen Libraries umgesetzt.

Traits

Datentypen können mittels Traits gruppiert werden. Traits können Methoden deklarieren und implementieren. Member können in Traits nicht definiert werden.

Implementierung

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 jeden Datentyp eine eindeutige Implementierung gibt.

Auto Traits werden mit dem Keyword auto markiert. Der Compiler implementiert sie für jeden Datentyp automatisch, falls er es für angebracht hält. Beispiele sind std::marker::Send und std::marker::Sync.

TODO: Blanket Implementations

Verwendung

Um eine Methode, die in einem Trait deklariert ist, aufrufen zu können, muss 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: TODO
• Dynamischer Polymorphismus: TODO
• Returnwert-Typ-Polymorphismus: TODO

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

Trait-Objekte:

• Der Trait muss object-safe sein. TODO
• Upcasting von Traits eines Trait-Objekts ist nicht möglich.
• Clonen ist nicht möglich. Siehe aber das Crate dyn-clone.

Inheritance

Traits können automatisiert vereinigt werden. Datenstrukturen und die für sie implementierten Methoden können jedoch nicht automatisiert vereinigt werden.

Trait Bounds

TODO Bei Funktionsargumenten und -Returnwerten, 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. Entwickler können sie nur als Trait Bound verwenden. Der Compiler validiert rekursiv, ob eine Datenstruktur die jeweils vorgegebenen Trait Bounds erfüllt.

• std::marker::Copy: erfüllt ein Datentyp den Trait-Bound Copy, so kann er durch den Compiler implizit dupliziert werden.
• std::marker::Send: erfüllt ein Datentyp den Trait-Bound Send, so kann höchstens 1 Thread exklusiven Zugang haben.
• std::marker::Sized:
• ein Datentyp erfüllt genau dann den Trait-Bound 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 können nur Referenz auf dem Stack abgelegt werden.
• Alle Typ-Parameter sind Sized, nicht jedoch bei Self in Traits, weil es Trait-Objekte verhindert.
• Diese Einschränkung kann mit ?Sized entfernt werden.
• Generics durchlaufen Monomorphization/Reification, daher muss Self: Sized sein. TODO
• std::marker::Sync: erfüllt ein Datentyp den Trait-Bound 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.
• std::marker::Unpin: TODO

Ownership

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 andere Ressourcen, wie geöffnete Dateien, Netzwerkverbindungen oder Locks.

Weil nicht mehr als ein Codebereich gleichzeitig vollen Zugriff haben kann, sind Fehler durch konkurrierenden Zugriff nicht möglich.

Clone, Copy

Die Besitzübertragung mittels Move ist außer bei primitiven Datentypen die Regel. Falls das nicht gewünscht ist, können die Daten vor der Übergabe dupliziert (geklont) werden. Somit wechselt nur das Duplikat den Besitzer. 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 std::clone::Clone implementiert ist.

TODO: std::borrow::ToOwned

Ist für den Datentyp hingegen der Marker Trait std::marker::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 solche und andere 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

Die Einschränkungen des Ownership-Modells sind in vielen Fällen zu restriktiv. Mittels Borrowing kann anderen Codebereichen temporärer Zugriff auf Daten gewährt (ausgeliehen) werden, ohne dass der Besitz abgegeben werden muss.

Es gibt zwei Arten von temporären Zugriffen:

• &T: gewährt temporär geteilten Zugriff
• &mut T: gewährt temporär exklusiven Zugriff.

TODO:

• std::convert::AsRef: TODO
• std::borrow::Borrow: TODO
• std::ops::Deref: TODO

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.

Asynchronous Rust

Informed polling, cooperative scheduling. TODO

• 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.

Wenn async Funktionen rekursiv aufgerufen werden sollen, muss der Result-Typ geboxed werden. Andernfalls hätte der Return-Wert-Typ - ähnlich bei rekursiven Enums - unendliche Größe. LocalBoxFuture und BoxFuture.

Einschränkungen

async Drop wird derzeit nicht unterstützt. async Closures stehen in Stable Rust noch nicht zur Verfügung

Trait-Methoden können nicht async sein. Als Workaround kann das Crate async-trait verwendet werden.

Implizites vs. Explizites

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: std::ops::Fn, std::ops::FnMut oder std::ops::FnOnce aufgerufen.
• Coercion: Datentypen können implizit in andere umgewandelt werden.
• Copy-Semantik: TODO
• Deref-Coercion: deref() aus dem Trait std::ops::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 bestimmten Code kann man den Compiler dafür nutzen, Eigenschaften von Datentypen entweder zu bestätigen oder mittels Fehlermeldungen zu erklären.

Erklären lassen:

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

Sicherstellen:

• 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 }
• die Thread-Sicherheit des Datentyps A:
• fn assert_send<T: Send>() {}; assert_send::<A>();
• fn assert_sync<T: Sync>() {}; assert_sync::<A>();
• die Object-Safety des Traits T:
• fn assert_object_safety(a: Box<dyn T>) {}

Explizites

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

Smart-Pointer

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

nicht thread-safe

„Nicht thread-safe“ bedeutet in Rust, 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
• std::cell::Cell:
• gibt keine Referenzen heraus, der Wert wird beim Schreiben und Lesen kopiert
• => eher für kleine Datentypen
• verwendet intern UnsafeCell
• std::cell::RefCell:
• gibt nur unique Referenzen heraus
• verwendet intern UnsafeCell
• im Modul std::rc:
• Reference Counting
• std::rc::Rc:
• gibt nur unique Referenzen heraus
• std::rc::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

optimieren

die Kompilierung beschleunigen

• Nicht benötigte Abhängigkeiten 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
• cargo check verwenden statt cargo build
• in Cargo.toml im Abschnitt [profile.dev] definieren:
• split-debuginfo = "unpacked": TODO

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" (per 01.06.2020 noch nicht in Rust): 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
• nach Lizenzen:
• cargo-deny
• cargo-lichking

made with makāmau