Are we Rust yet? Warum alle Rust lieben – aber kaum jemand es nutzt

# Are we Rust yet? ### Warum alle Rust lieben – aber kaum jemand es nutzt --- ## Rust Blog  <a href="https://blog.rust-lang.org/2025/12/19/what-do-people-love-about-rust/" class="slide-sources">blog.rust-lang.org/2025/12/19/what-do-people-love-about-rust/</a> --- ## Developer Survey  Jährliche Befragung von Entwicklern weltweit ~40000 Teilnehmer von Anfänger bis Professionals <a href="https://survey.stackoverflow.co/2025/technology" class="slide-sources">survey.stackoverflow.co/2025/technology</a> --- ## Admired and Desired (2025)  Blau: Desired // Rot: Admired <a href="https://survey.stackoverflow.co/2025/technology" class="slide-sources">survey.stackoverflow.co/2025/technology</a> --- ## Admired and Desired (2024)  <a href="https://survey.stackoverflow.co/2024/technology" class="slide-sources">survey.stackoverflow.co/2024/technology</a> --- ## Admired and Desired (2023)  <a href="https://survey.stackoverflow.co/2023/technology" class="slide-sources">survey.stackoverflow.co/2023/technology</a> --- ## Most popular technologies  <a href="https://survey.stackoverflow.co/2025/technology" class="slide-sources">survey.stackoverflow.co/2025/technology</a> --- ## Jetbrains Dev Report  <a href="https://devecosystem-2025.jetbrains.com/" class="slide-sources">devecosystem-2025.jetbrains.com/</a> --- ## Jetbrains Dev Report  <a href="https://devecosystem-2025.jetbrains.com/" class="slide-sources">devecosystem-2025.jetbrains.com/</a> --- ## Jetbrains Dev Report  <a href="https://devecosystem-2025.jetbrains.com/" class="slide-sources">devecosystem-2025.jetbrains.com/</a> --- ## Jetbrains Dev Report  <a href="https://devecosystem-2025.jetbrains.com/" class="slide-sources">devecosystem-2025.jetbrains.com/</a> --- ## Das Paradox Rust wird geliebt ...aber "Liebe" ist nicht gleich "Einsatz in der Firma" > "Most admired" heißt: Wer’s nutzt, will’s behalten. > > Nicht: "alle nutzen’s". --- ## Die Leitfrage "Are we Rust yet?" ist keine Ja/Nein-Frage – sondern: **für welchen Kontext**? - Web-Backends? ✅ oft ja - Embedded? ✅/⚠️ je nach MCU/Toolchain/Team - ML? ⚠️ im Aufbau - Gaming? ⚠️ "blocks vorhanden, glue fehlt" - Safety/ASIL? ✅ (mit Einschränkungen/Tooling) --- ## Agenda: 5 Akte 1) Rust DNA & warum es entstand 2) Realität: Adoption, Pain Points, Ökosystem 3) Deep Dive: Web 4) Deep Dive: Embedded + Safety/ASIL + Kernel 5) Adoption-Playbook + Decision Matrix --- ## Akt 1: Was will Rust lösen? "reliable + efficient systems" **ohne GC/Runtime**, als Drop-in für C mögl. - Stabilitätsversprechen seit 1.0 (15.05.2015) - Sicherheit/Correctness als Type-System-Problem - weniger Debugging-Zeit, weniger "mysteriöse Crashes" - Wichtig: Rust ist nicht "C++ mit besserer Syntax", sondern anderes Sicherheitsmodell <a href="https://blog.rust-lang.org/2015/05/15/Rust-1.0/" class="slide-sources">blog.rust-lang.org/2015/05/15/Rust-1.0/</a> --- ## Release Train Rust liefert kontinuierlich – alle ~6 Wochen – und hält trotzdem Stabilität. - Release-Übersicht zeigt den Takt - Planbare Evolution (Editions als "opt-in breaking-ish changes") - Rust ist "modern", aber mit bewusstem Stabilitätsmechanismus <a href="https://blog.rust-lang.org/releases/" class="slide-sources">blog.rust-lang.org/releases/</a> --- ## Release Train  <a href="https://blog.rust-lang.org/releases/" class="slide-sources">blog.rust-lang.org/releases/</a> --- ## Meilensteine Editions markieren die großen Sprünge – ohne Legacy zu sprengen. - [2015](https://blog.rust-lang.org/2015/05/15/Rust-1.0/): Rust 1.0 (Stability Promise) - [2021](https://blog.rust-lang.org/2021/10/21/Rust-1.56.0/): Rust 2021 (1.56) - [2024](https://blog.rust-lang.org/2025/02/20/Rust-1.85.0/): Rust 2024 (1.85) - [2025](https://blog.rust-lang.org/2025/05/15/Rust-1.87.0/): 10 Jahre Rust (1.87) --- ## Spring zu Rust 2021 Rust 2021 war "Quality of Life", Tooling-Verbesserung & weniger Churn für Teams - Edition als kontrollierter Evolutionsschritt - Migration weitgehend automatisierbar (`cargo fix`) - Editions sind "Strategie gegen Ökosystem-Chaos" <a href="https://blog.rust-lang.org/2021/05/11/edition-2021/" class="slide-sources">blog.rust-lang.org/2021/05/11/edition-2021/</a> --- ## Rust 2024: Der größere Cut Rust 2024 bringt größere semantische/ergonomische Änderungen, bleibt aber upgradebar. - Beispiel: `extern`-Blöcke jetzt `unsafe` - `cargo fix` als Migrationspfad Rust verschiebt Grenzen, aber versucht "mechanische Migration". <a href="https://blog.rust-lang.org/2025/02/20/Rust-1.85.0/" class="slide-sources">blog.rust-lang.org/2025/02/20/Rust-1.85.0/</a> --- ## Rust in einem Satz "Systems-Performance + Compile-Time Safety" statt "Runtime Safety". - Kein GC, i.d.R. keine Runtime - Safety als Default (mit `unsafe` als Escape Hatch) <a href="https://doc.rust-lang.org/book/" class="slide-sources">doc.rust-lang.org/book/</a> --- ## Ownership: Das mentale Modell Rust "modelliert Verantwortung" für Speicher – explizit, statisch. - Ein Owner pro Ressource - Move/Copy als bewusste Semantik - Borrowing statt Alias + Mutability Chaos - Ziel: "Wer darf was wie lange?" <a href="https://doc.rust-lang.org/book/ch04-00-understanding-ownership.html" class="slide-sources">doc.rust-lang.org/book/ch04-00-understanding-ownership.html</a> --- ## Borrow Checker: Warum er nervt (und hilft) Borrow Checker ist ein *Compiler-Reviewer*, der viele Bugklassen vor Runtime eliminiert - Keine Data Races in Safe Rust - Alias + Mutation Regeln - "Er ist streng, aber konsistent" - Strenge ist *Kosten* (Learning Curve), aber auch *Asset* (Qualität) <a href="https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html" class="slide-sources">doc.rust-lang.org/book/ch04-02-references-and-borrowing.html</a> --- ## Beispiel: Borrow Checker Rust verhindert "use-after-free / dangling refs" als Kompilierfehler ```rust fn main() { let s = String::from("hi"); let r = &s; println!("{r}"); drop(s); // <- illegal } ``` <a href="https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html" class="slide-sources">doc.rust-lang.org/book/ch04-02-references-and-borrowing.html</a> --- ## Unsafe: Der Deal Rust ist nicht "magisch sicher" — aber Unsafe ist *lokalisierbar* und reviewbar. * Unsafe dort, wo nötig (FFI, Kernel, Embedded Register) * Idealerweise: unsafe kapseln, safe API anbieten * Wichtig für Embedded/Safety/Kernels: unsafe ist Realität <a href="https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html" class="slide-sources">doc.rust-lang.org/book/ch19-01-unsafe-rust.html</a> <!-- <a href="https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html" class="slide-sources">security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html</a> --> --- ## Vergleich * **C++**: maximale Kontrolle, aber Safety teuer (Tools/Reviews/Guidelines) * **Java**: Safety via VM/GC, weniger Kontrolle, langsameres Performance-Profil * **JS/TS**: schnell iterierbar, Runtime dynamisch, Perf/Concurrency langsam * **Rust**: Kontrolle + Safety via Compiler, dafür steilere Lernkurve & Compile-Time Kosten <a href="https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html" class="slide-sources">security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html</a> --- ## Akt 2: Realität – Warum kaum genutzt? Adoption ist ein Systemproblem: People + Process + Product + Platform * Hiring/Skill * Toolchains/Interop * Compile Times & Iteration Speed * Regulatorik & Zertifizierungen * Ökosystem-Reife je Domäne <a href="https://blog.rust-lang.org/2025/02/13/state-of-rust-survey-2024-results/" class="slide-sources">blog.rust-lang.org/2025/02/13/state-of-rust-survey-2024-results/</a> --- ## Top Pain: Compile Times Compile Times sind ein echter Adoption-Killer – besonders bei großen Codebases * Iterations-Loop ist Produktivität * CI-Zeiten, Laptop-Fans, Developer Frust * Das Problem ist bekannt und aktiv adressiert <a href="https://rust-lang.github.io/rustc-perf-survey-2025/" class="slide-sources">rust-lang.github.io/rustc-perf-survey-2025/</a> --- ## Warum Leute Rust verlassen Unter Ex-Rust-Usern ist "slow compile times" ein sehr häufiger Grund * Nicht nur "Skill Issue" * Große Projekte = spürbarer * Rust gewinnt im "Correctness/Quality", verliert aber im "edit-compile-run" Gefühl * Wie kompensieren Teams das? (Caching, Arch, workspace split, etc.) <a href="https://rust-lang.github.io/rustc-perf-survey-2025/" class="slide-sources">rust-lang.github.io/rustc-perf-survey-2025/</a> --- ## Ökosystem-Reife: "Are we … yet?" Rust ist nicht "fertig/ unfertig", sondern domänenspezifisch reif * Web: sehr stark [arewewebyet.org/](https://arewewebyet.org/) * Embedded: stark, aber abhängig von HAL/Toolchain ([tweede golf](https://tweedegolf.nl/en/blog/101/are-we-embedded-yet)) * Gaming: "blocks vorhanden" [arewegameyet.rs/](https://arewegameyet.rs/) * ML: "viel Bewegung, aber noch fragmentiert" [arewelearningyet.com/](https://www.arewelearningyet.com/) --- ## Akt 3: Deep Dive Web Web/Network Services profitieren maximal von Rusts Kombination aus Safety + Performance. * Viel I/O, viel Concurrency * Memory Safety + Durchsatz + Tail Latency * "Fearless concurrency" als Praxisvorteil * In Web ist "Bug" oft: Security incident, outage, data corruption * Rust verschiebt viele Fehler in die Build-Phase <a href="https://github.com/cloudflare/pingora" class="slide-sources">github.com/cloudflare/pingora</a> --- ## Tokio & async: Das Rückgrat Rusts **async** ist mächtig – aber komplexer als "einfach Threads" * `async/await` + Runtime (Tokio) * Kontrolle über Backpressure / Ressourcen * Fehlerklassen ändern sich (weniger Races, mehr "async design bugs") * Für Einsteiger: "async ist nicht gratis" * Trotzdem: Im High-Scale Web ist diese Kontrolle Gold wert <a href="https://tokio.rs/" class="slide-sources">tokio.rs/</a> --- ## Web Frameworks: Axum/Actix & Co. Rust Web ist produktionsfähig – vor allem für Services, APIs, Proxies, Infra * Axum (Tokio-basiert), Actix-web (performant) * Gute Building Blocks: serde, tower, tracing, reqwest... * Kein Framework-Pitch! Ökosystem hat die "Standard-Bausteine" <a href="https://arewewebyet.org/" class="slide-sources">arewewebyet.org/</a> <!-- <a href="https://github.com/tokio-rs/axum" class="slide-sources">github.com/tokio-rs/axum</a> --> <!-- <a href="https://actix.rs/" class="slide-sources">actix.rs/</a> --> --- ## Case Study: Pingora Rust skaliert in echter Internet-Infrastruktur (Proxy/HTTP Stack) – inkl. OSS. * Pingora ist Cloudflares Rust-Framework für Network Services (open sourced) * Gleichzeitig: klare Caveats (API stability, pre-1.0) * Rust da, wo C früher alternativlos war <a href="https://github.com/cloudflare/pingora" class="slide-sources">github.com/cloudflare/pingora</a> --- ## Web-Realität: Auch Rust hat CVEs Memory Safety ist nicht "0 Bugs" – aber Bug-Klassen verschieben sich * Beispiel: Request smuggling in Pingora (klassischer Protokoll-/Parsing-Bug) * Rust verhindert nicht automatisch Logikfehler * "Security ist mehr als Memory Safety" * Rust reduziert *eine* riesige Klasse, aber du brauchst weiterhin Threat Modeling, Reviews, Tests <a href="https://blog.cloudflare.com/resolving-a-request-smuggling-vulnerability-in-pingora/" class="slide-sources">blog.cloudflare.com/resolving-a-request-smuggling-vulnerability-in-pingora/</a> --- ## WASM: Rust als "Assembly mit Types" Rust + WASM ist stark – aber die Tooling-Landschaft verändert sich spürbar * Rust eignet sich gut für WASM (klein, kontrolliert) * Ecosystem ist in Bewegung (Docs/Tooling wandern) * Viele nutzen Rust für WASM, aber nicht jedes Setup ist "batteries included" <a href="https://rustwasm.github.io/docs/book/" class="slide-sources">rustwasm.github.io/docs/book/</a> --- ## Akt 4: Deep Dive Embedded Embedded ist "wo Rust Sinn ergibt" – aber Toolchain/Hardware entscheidet * `no_std`, Kontrolle, deterministische Ressourcen * Memory Safety gegen Hard-to-debug Bugs * Gleichzeitig: Debugging, HAL-Reife, Vendor-Support <a href="https://docs.rust-embedded.org/book/" class="slide-sources">docs.rust-embedded.org/book/</a> --- ## Embedded Rust Stack Embedded Rust hat echte Bausteine: HAL, Debugging, Logging, Async/RT * [Embedded Rust Book](https://docs.rust-embedded.org/book/) (Einstieg) * [`embedded-hal`](https://github.com/rust-embedded/embedded-hal) als Trait-Schicht * [probe.rs](https://probe.rs/) (Flash/Debug) * [defmt](https://defmt.ferrous-systems.com/) (Logging) * [Embassy](https://embassy.dev/) (async embedded) --- ## `no_std`: Der wichtigste Embedded-Schalter `std` ist optional – Kernel & Embedded arbeiten häufig `no_std` * Kernel: nur `core` (kein `std`) * Embedded: häufig kein Allocator, keine OS-Services * Brücke zum Linux Kernel: selbe Grundidee, andere Constraints <a href="https://docs.kernel.org/rust/general-information.html" class="slide-sources">docs.kernel.org/rust/general-information.html</a> --- ## Async auf MCUs (Embassy) Async kann "State Machines" lesbar machen – wenn das Tooling passt * Concurrency ohne klassischen RTOS-Thread-Overhead * Aber: Timing/Interrupts/Peripherals bleiben tricky * Wichtig: Nicht überall async einsetzen – aber für I/O-heavy Embedded oft sehr angenehm <a href="https://embassy.dev/" class="slide-sources">embassy.dev/</a> --- ## Embedded Pain Points Die Bremsen sind selten "Rust die Sprache", sondern: Umgebung * HALs nicht überall gleich reif * Debugging je Vendor/Probe/IDE * `unsafe` an Register/FFI-Stellen unvermeidlich * Build-Zeiten auf CI/Targets * "Pilotprojekt" statt Big Bang Rewrite <a href="https://docs.rust-embedded.org/book/" class="slide-sources">docs.rust-embedded.org/book/</a> <!-- <a href="https://blog.rust-lang.org/2025/09/04/rust-compiler-performance-survey-2025/" class="slide-sources">blog.rust-lang.org/2025/09/04/rust-compiler-performance-survey-2025/</a> --> --- ## Rust + Safety-Critical: Wo kommt ASIL ins Spiel? In Safety geht’s nicht nur um Sprache, sondern um **Tool Qualification & Prozess** * ISO 26262 / ASIL fordert nachweisbare Toolchain-Eigenschaften * "Trust your compiler" reicht nicht – du brauchst Artefakte * Kernfrage: "Kann ich Rust in ASIL-D-Projekten einsetzen?" * Antwort: Ja, aber Tooling/Prozess muss passen <a href="https://ferrocene.dev/" class="slide-sources">ferrocene.dev/</a> --- ## Ferrocene: Qualified Rust Toolchain Ferrocene adressiert Tool-Qualification für Safety-Standards. * Ziel: qualifizierbare Toolchain für u.a. ISO 26262 (ASIL D), IEC 61508 (SIL 4) * TÜV SÜD spielt als Prüfer mit Rolle (je nach Paket/Scope) * keine "Rust stable toolchain", sondern Produkt/Bundle mit Safety Artefakten * Scope/Versionen beachten! <a href="https://ferrocene.dev/" class="slide-sources">ferrocene.dev/</a> --- ## Safety-Prinzip: "Unsafe budget" Safety in Rust heißt: unsafe minimieren, kapseln, auditieren * Unsafe nur in klaren Modulen * Safety Comments / Invariants dokumentieren * Reviews & Tooling auf unsafe fokussieren <!-- <a href="https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html" class="slide-sources">doc.rust-lang.org/book/ch19-01-unsafe-rust.html</a> --> <a href="https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html" class="slide-sources">security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html</a> --- ## Rust im Linux Kernel: Status Rust ist im Kernel mainline – aber als *Experiment* und noch nicht überall "production drivers" * Rust support merged in **v6.1** * Fokus: Abstractions, Infrastruktur, Treiber-Experimente * Reality-Check: selbst hier läuft es bewusst vorsichtig <a href="https://docs.kernel.org/rust/" class="slide-sources">docs.kernel.org/rust/</a> --- ## Kernel-Rust: "no_std" in echt Kernel Rust zeigt: Rust ohne `std` ist Alltag – aber mit Constraints * Build/Toolchain Anforderungen * Dokumentierte Guidelines & Policies * "Rust ist mehr als nur App-Sprache" <!-- <a href="https://docs.kernel.org/rust/quick-start.html" class="slide-sources">docs.kernel.org/rust/quick-start.html</a> --> <a href="https://rust-for-linux.com/" class="slide-sources">rust-for-linux.com/</a> --- ## Android: Memory Safety Journey (2022 → 2025) Android zeigt mit Daten: Memory Safety Bugs sinken, Rust skaliert organisatorisch * 2022: "Memory safe languages in Android 13" * 2024: "Eliminating memory safety vulnerabilities at the source" * 2025: "move fast and fix things" (Produktivitätsmetriken) * stärkste "Rust-in-der-Praxis" Quellen, zeigen Security & Delivery-Metriken <a href="https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html" class="slide-sources">security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html</a> <!-- <a href="https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html" class="slide-sources">security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html</a> <a href="https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html" class="slide-sources">security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html</a> --> --- ## Android 2025 Rust ist nicht nur sicher, sondern oft "faster to ship" * kann *Stabilität* und *Delivery* verbessern (weniger Rollbacks, schnellere Reviews) * Memory safety vulnerabilities < 20% (2025 Datenpunkt) * ~4x lower rollback rate (für medium/large changes) * ~25% weniger Zeit in Code Review (vs C++) * => weniger "Fehlerkosten" & Review-Friction <a href="https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html" class="slide-sources">security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html</a> --- ## AWS Firecracker: Rust in Cloud Isolation Rust läuft in Security-sensitiver Infrastruktur (MicroVM VMM) – und wird verifiziert * Firecracker: Rust-basierte MicroVM Tech in AWS * Kani Model Checking als zusätzliches Assurance-Tool * "Safety mindset" auch außerhalb Automotive <a href="https://aws.amazon.com/blogs/opensource/how-open-source-projects-are-using-kani-to-write-better-software-in-rust/" class="slide-sources">aws.amazon.com/blogs/opensource/how-open-source-projects-are-using-kani-to-write-better-software-in-rust/</a> --- ## Akt 4b: Gaming – "blocks vorhanden" Rust Gamedev lebt – aber du musst viel "glue" selbst bauen * Gute Renderer/Libs existieren * Engines/Toolchains noch fragmentiert <a href="https://arewegameyet.rs/" class="slide-sources">arewegameyet.rs/</a> --- ## Akt 4c: ML – viel Bewegung, nicht "default choice" Rust ML ist spannend (Performance, Safety), aber Python-Ökosystem ist riesig * Rust eignet sich für Inferenz/Systems-Teile * Trainings-Ökosystem & Tooling im Aufbau <a href="https://www.arewelearningyet.com/" class="slide-sources">arewelearningyet.com/</a> --- ## Akt 5: Wo Rust heute *wirklich* gewinnt Rust ist am stärksten, wenn *Kosten von Bugs* hoch sind * Security-relevante Komponenten (Parser, Netzwerk, Sandbox, Kernel-nah) * Concurrency-heavy Services * Embedded/Systems mit klaren Constraints * Libraries mit Stable API, die von vielen genutzt werden --- ## ...und wo Rust heute (noch) scheitert Rust ist nicht "kostenlos" – die Tradeoffs sind real * Learning Curve (Ownership/async) * Compile Times (große Workspaces) * Ökosystem-Lücken in Nischen (GUI, manche Embedded Targets, ML) * Interop-Aufwand (Buildsysteme, ABI, Tooling) --- ## Adoption-Playbook Rust erfolgreich einführen heißt: klein starten, Evidence sammeln, Interop sauber machen 1. Pilot in einem "high leverage" Modul 2. Unsafe-Zonen definieren + Review-Regeln 3. Build/CI optimieren (Caching, workspace split, incremental) 4. Interop-Strategie (FFI, boundaries, ownership) 5. Enablement: Training + Pairing + Guidelines --- ## Decision Matrix: Wann ist Rust die richtige Wahl? Rust ist passend, wenn du 3+ dieser Punkte hast: * Memory Safety als echtes Risiko (Security/Hard-to-debug) * Concurrency / Parallelität relevant * Performance/Footprint wichtig * Langfristige Wartbarkeit & Correctness wichtiger als "speed of prototyping" * Du kannst Tooling/Hiring/Training investieren --- ## Corpuls  Für - Menschen - Leben Medizintechnik in der Rettung <a href="https://corpuls.world/" class="slide-sources">corpuls.world</a> --- ## Corpuls  <a href="https://corpuls.world/" class="slide-sources">corpuls.world</a> --- ## Q: Are we Rust yet? **Ja**, in Web/Infra & zunehmend Embedded/Safety – **aber** nicht überall "default" * Rust ist "industrial grade" * Adoption ist domänenspezifisch * Der Flaschenhals ist oft Organisation, nicht Sprache > "Geliebt" ist real – aber "genutzt" braucht Infrastruktur. --- ## Mehr?! [rust-augsburg.github.io/meetup](rust-augsburg.github.io/meetup) [munich-embedded.com](munich-embedded.com) [WieErWill.Dev](WieErWill.Dev)

END OF BRIEFING

MAIL:
robert.jeutter@wieerwill.dev

MASTODON:
https://chaos.social/@wieerwill

LINKEDIN:
https://www.linkedin.com/in/wieerwill

WEB:
https://wieerwill.dev