Rust

Die Lernkurve ist steil. Der Compiler ist dein Lehrer, aber er ist streng.

• Cargo: Der beste Paketmanager der Welt. cargo new, cargo build, cargo test. Alles dabei.
• Anwendung: CLI-Tools (ripgrep), Web-Server (Axum), Wasm-Module, Embedded Devices.

1. Zero Cost Abstractions

In Java kostet jede Abstraktion (Interface, Lambda) Performance. In Rust kompiliert alles weg. Ein Iterator in Rust ist genauso schnell wie eine manuelle for-Schleife in C.

2. Concurrency

"Fearless Concurrency". Der Compiler verbietet Data Races. Du kannst nicht versehentlich von zwei Threads ungeschützt auf eine Variable schreiben. Der Compiler stoppt dich. Das macht Multithreading viel einfacher wartbar.

1. Alias Analysis & The Borrow Checker's Graph

Das Kernkonzept von Rusts Speed und Safety liegt in der Alias Analysis. Wenn eine Funktion im Assembler generiert wird, optimiert LLVM massiv. Wenn es zwei C-Pointer gibt, die theoretisch auf denselben Speicher zeigen könnten (Aliasing), muss C pessimistisch alle L3-Caches in jedem Schleifendurchlauf in das RAM flushen (Pointer Aliasing Problem), was den CPU-Speed fesselt. Rusts Borrow Checker setzt eine brutale mathematische Regel durch: Zu jedem Zeitpunkt gibt es entweder mehrere Immutable References (&T) ODER genau eine Mutable Reference (&mut T). Dies führt zu null Overlap. LLVM erhält im Compiler-Pass das "Noalias" Meta-Tag. Die Caches dürfen Vektor-Operationen blind vorziehen (SIMD), ohne auf Race Conditions prüfen zu müssen. Rusts Safety generiert aus der Typsicherheit im Nebenprodukt signifikant aggressiver optimierten LLVM-Bitcode als C/C++ es legal jemals dürfte.

2. Unsafe Rust & Soundness Boundaries

Der Mythos "Rust ist zu 100% sicher" ist naiv. Memory-MAPPED Hardware, das Schreiben von Thread-Planern, C-FFIs oder hochoptimierte Ring-Buffer sind in reinem Safe Rust unmöglich (da der Compiler Hardware-Magie nicht beweisen kann). Die Lösung ist der Scope unsafe { ... }. Hier übernimmst du die Rolle des Borrow-Checkers manuell. Das Geniale: Dies zwingt Entwickler zur modularen Isolation. Während in C++ eine Null-Pointer-Exception aus absolut einer Million Files triggern kann (da alles unsicher ist), beschränkt Rust im Projekt den Suchradius für RAM-Corruption auf die winzigen $< 2%$ Files, die unsafe Code tragen. Das Konstrukt nennt sich "Soundness": Safe Rust Code darf niemals kaputtgehen, selbst wenn er Unsafe Code aufruft. Die Unsafe-API fungiert als dichte Schale um dreckige Assembler-Tricks.

3. Drop Trait, RAII und Smart Pointers

Java löst den Heap über den langsamen, pausierenden Garbage Collector. C lässt dich malloc / free per Hand tippen (mit der Konsequenz von "Use-After-Free"). Rust meistert das über das RAII Muster (Resource Acquisition Is Initialization) über das Drop Trait. Wird im Stack eine Variable angelegt, trackt der Lexer ihren Lifespan-Scope { ... }. Wenn der Scope schließt, injiziert der rustc-Compiler den free() Befehl unsichtbar und deterministisch in das Executable (genau wie in C++ mit Destruktoren). Bei Zuweisungen im RAM (let x = String::new()) ist es ein Move-Semantics System. Das alte x ist ungültig, es gibt keine Shallow Copy. Braucht man Shared Ownership (z.B. Multithreading), bedienten C-Macher sich Pointern. Rust zwingt zur Benutzung von Smart Pointern (ArC - Atomic Reference Counted Pointer). Wenn der ArC-Counter im Threading sauber auf null dekrementiert, verpufft der Heap deterministisch.