Rust ist möglicherweise kein geeignetes Werkzeug für User-Space-Software mit massiver Nebenläufigkeit

• Dieser Artikel diskutiert die Herausforderungen beim Einsatz von Rust für User-Space-Software mit massiver Nebenläufigkeit.
• Das asynchrone Modell von Rust wurde entwickelt, um zwei Kernkonzepte des modernen Computings zu handhaben: Nebenläufigkeit und Parallelität.
  • Parallelität umfasst die gleichzeitige Ausführung von Code auf mehreren CPUs.
  • Nebenläufigkeit umfasst das Zerlegen eines Problems in unabhängige Teile, die ohne feste Reihenfolge oder nur mit teilweiser Reihenfolge ausgeführt werden.
• Der Artikel hebt die Grenzen der Nutzung mehrerer Prozesse für Nebenläufigkeit hervor, da die Kommunikation zwischen Prozessen teuer ist.
• Als Alternative werden Threads genannt, also Prozesse, die sich denselben Speicher teilen, doch sie können komplexe Probleme wie Race Conditions und Deadlocks verursachen.
• Tony Hoares Aufsatz von 1978, "Communicating Sequential Processes", schlug vor, dass Threads Warteschlangen oder Kanäle verwenden, um sich gegenseitig Nachrichten zu senden, was mehrere Vorteile bietet, darunter prozessähnliche Isolation und einfacheres Debugging.
• Rusts Standardbibliothek enthält Kanäle unter std::sync::mpsc::sync_channel.
• Für Probleme, die ein hohes Maß an Nebenläufigkeit erfordern, etwa ein Webserver mit Verbindungen zu Zehntausenden von Nutzern, reichen Threads jedoch möglicherweise nicht aus.
• Rust verwendet für solche Situationen das Modell "async/await": Wenn eine Funktion als asynchron markiert ist, gibt sie ein Future oder Promise zurück, auf dessen Ergebnis gewartet werden kann.
• Trotz seiner Vorteile bringt asynchrones Rust Herausforderungen mit sich, etwa die Notwendigkeit, den Compiler davon zu überzeugen, dass alles in Ordnung sein wird. Das kann schwieriger sein als bei nativen Threads.
• Als Lösung wird die Nutzung von "atomarer Referenzzählung" oder Arc vorgeschlagen, doch das ist kein Allheilmittel, da dadurch Probleme entstehen können, die denen eines Garbage Collectors ähneln.
• Der Artikel schließt mit der Einschätzung, dass Rust trotz seiner Stärken in anderen Bereichen möglicherweise nicht das optimale Werkzeug für User-Space-Software mit massiver Nebenläufigkeit ist.

[GN⁺]

Hacker-News-Kommentare

• Der Autor entwickelt einen hochperformanten Metaverse-Client in Rust, der große Datenmengen in Echtzeit verarbeiten muss.
• Das Projekt des Autors nutzt mehrere Threads für verschiedene Aufgaben wie Grafik-Rendering, Verarbeitung von Netzwerk-Events und Asset-Loading.
• Rust war für dieses Projekt nützlich, und der Autor hat normalerweise etwa einmal im Jahr speicherbezogene Abstürze erlebt, die durch den „unsafe“-Code anderer verursacht wurden.
• Der Autor kritisiert, dass Rust zwar keine Race Conditions habe, aber nicht frei von Deadlocks sei, und schlägt die Notwendigkeit eines statischen Deadlock-Analysers vor.
• Der Autor kritisiert die weite Verbreitung von async in Rust und argumentiert, dass es für rechengebundene Aufgaben ungeeignet und mit Threads, die mit mehreren Prioritäten laufen, nicht kompatibel sei.
• Der Autor meint, dass Rusts Single Ownership zusammen mit Rückwärtsreferenzen zwar ein gewöhnliches Bedürfnis sei, aber zu schwer umzusetzen.
• Der Autor glaubt, dass das Rust-Gaming-Ökosystem für ernsthafte Spieleentwicklung nicht bereit sei, und verweist auf das Fehlen von Nicht-Spielzeug-Grafik in Rust.
• Andere Kommentare stimmen zu, dass async Rust herausfordernd und oft unnötig sei, und schlagen vor, dass Gos Ansatz, alles sync zu machen und einen einzelnen async-Kanal zu verwenden, besser sein könnte.
• Einige Kommentatoren kritisieren die weite Verbreitung von async im Rust-Ökosystem und behaupten, dass dies Programme dazu zwinge, vollständig async zu werden oder sich für viele Dinge auf die tokio-Crate zu verlassen.
• Einige Kommentatoren schlagen vor, dass Rusts async-Funktionalität noch in Entwicklung sei und Kritik am aktuellen Zustand verfrüht sei.
• Ein Kommentator argumentiert, dass Rusts Arc nicht unbekannt sei, sondern davon abhänge, wo und wie man es besitzt, und meint, der Autor versuche, sein früheres gedankliches Modell Rust aufzuzwingen.
• Einige Kommentatoren lehnen die Verwendung von async/await generell ab und argumentieren, dass dies Sprache und Ökosystem in zwei Hälften teile und langfristige Probleme verursache.
• Ein Kommentator schlägt vor, dass das richtige Primitive für Concurrency Hoares Communicating Sequential Processes sei, abgebildet auf Green Threads, wie es in Java (seit JDK17 – Java Virtual Threads), Go und Kotlin umgesetzt wurde.
• Ein Kommentator schlägt vor, dass es ein vernünftiger Kompromiss sei, ein unsafe-Crate wie async-scoped zu verwenden, um die meisten Bugs abzufangen, die sonst in C++ geschrieben worden wären.