Are we Rust yet?

Warum alle Rust lieben – aber kaum jemand es nutzt

Rust Blog

Developer Survey

Jährliche Befragung von Entwicklern weltweit

~40000 Teilnehmer von Anfänger bis Professionals

Admired and Desired (2025)

Blau: Desired // Rot: Admired

Admired and Desired (2024)

Admired and Desired (2023)

Most popular technologies

Jetbrains Dev Report

Jetbrains Dev Report

Jetbrains Dev Report

Jetbrains Dev Report

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

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

Release Train

Meilensteine

Editions markieren die großen Sprünge

– ohne Legacy zu sprengen.

• 2015 🔗: Rust 1.0 (Stability Promise)
• 2021 🔗: Rust 2021 (1.56)
• 2024 🔗: Rust 2024 (1.85)
• 2025 🔗: 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”

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

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)

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?“

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)

Beispiel: Borrow Checker

Rust verhindert “use-after-free / dangling refs” als Kompilierfehler

fn main() {
    let s = String::from("hi");
    let r = &s;
    println!("{r}");
    drop(s); // <- illegal
}

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

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

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

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

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

Ökosystem-Reife: “Are we … yet?”

Rust ist nicht “fertig/ unfertig”, sondern domänenspezifisch reif

• Web: sehr stark arewewebyet.org/ 🔗
• Embedded: stark, aber abhängig von HAL/Toolchain (tweede golf 🔗)
• Gaming: “blocks vorhanden” arewegameyet.rs/ 🔗
• ML: “viel Bewegung, aber noch fragmentiert” 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

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

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”

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

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

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”

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

Embedded Rust Stack

Embedded Rust hat echte Bausteine: HAL, Debugging, Logging, Async/RT

• Embedded Rust Book 🔗 (Einstieg)
• embedded-hal 🔗 als Trait-Schicht
• probe.rs 🔗 (Flash/Debug)
• defmt 🔗 (Logging)
• Embassy 🔗 (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

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

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

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

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!

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

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

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”

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

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

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

Akt 4b: Gaming – “blocks vorhanden”

Rust Gamedev lebt – aber du musst viel “glue” selbst bauen

• Gute Renderer/Libs existieren
• Engines/Toolchains noch fragmentiert

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

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

Corpuls

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

munich-embedded.com

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