Enttäuschende Punkte, die mir nach etwa 10 Jahren Nutzung (und Liebe) zu Rust aufgefallen sind

Ich nutze Rust seit ungefähr 10 Jahren und liebe diese Sprache wirklich. Trotzdem gibt es auch einige enttäuschende Punkte. Hier ist die Liste.

1. Probleme mit Result<T, E>

Dass Rusts Fehlerbehandlung klar und erzwungen ist, ist großartig. In der Praxis ist sie jedoch oft umständlich.

• Schwierigkeiten für Bibliotheksautoren: Das Erstellen neuer Fehlertypen und deren Konvertierung ist mühsam. Besonders lästig ist es, bei jeder neuen Abhängigkeit die Fehlertypen jeder Funktion zum Wrapper-Fehlertyp hinzufügen zu müssen.
• Umständlichkeit im Anwendungscode: Wichtiger als der genaue Grund, warum eine Funktion fehlschlägt, ist oft, den Fehler nach oben weiterzureichen und dem Nutzer das Ergebnis zu zeigen. Anders als Java liefert Rust beim Weiterreichen keinen Backtrace, wodurch sich die Ursache eines Problems nur schwer nachvollziehen lässt.

2. Die Flexibilität des Modulsystems

Rusts Modulsystem ist so flexibel, dass es dadurch oft eher unpraktisch wird.

• Zu viel Flexibilität: Man kann Typen re-exportieren oder Zugriffsrechte sehr fein abstimmen, aber das kann dazu führen, dass versehentlich Typen offengelegt werden, die man gar nicht exportieren wollte.
• Probleme mit der Orphan Rule: Es wird empfohlen, Projekte auf mehrere Crates aufzuteilen, aber die Orphan Rule steht dabei manchmal im Weg.

3. Compile-Zeiten und IDE-Tools

Rusts Compile-Zeiten und die Fehlerprüfung der IDE-Tools sind zu langsam.

• Lange Compile-Zeiten: In großen Projekten führt eine Änderung an nur einer Funktion dazu, dass die gesamte Crate neu kompiliert wird, was sehr ineffizient ist.
• Langsame Reaktionsgeschwindigkeit der IDE: Rust Analyzer fühlt sich an, als würde es bei jedem Tastendruck das Projekt neu indizieren, was besonders in großen Projekten problematisch ist.

Fazit

Rust ist zwar meine Lieblingssprache, aber diese enttäuschenden Punkte gibt es trotzdem. Ich frage mich, ob andere Nutzer dieselben Probleme haben.

[ranolp]

Bei der Fehlerbehandlung ist es praktisch, für Bibliotheken snafu/thiserror und für Anwendungen eyre/anyhow zu installieren und zu verwenden.

[y15un]

Die Schwierigkeiten von Bibliotheksautoren: [..snip..] Jedes Mal, wenn man eine Abhängigkeit hinzufügt, ist es besonders lästig, den Fehlertyp jeder Funktion zum Wrapper-Fehlertyp hinzuzufügen.

Diesen Punkt kann ich wirklich schmerzlich nachvollziehen. Es ist nicht nur ein- oder zweimal vorgekommen, dass ich ein cratespezifisches Fehler-enum erstellt und jedes Mal für die aus Abhängigkeiten hereingezogenen Fehlertypen ein impl From<ExtError> for Error geschrieben habe und dabei dachte: „Wie nervig ist das denn …“

[eususu]

Vielleicht liegt es daran, dass ich noch nicht richtig angefangen habe, aber ich würde diese Enttäuschung gern einmal selbst erleben.
Danke für den guten Artikel~

[undercat]

Vielen Dank für den guten Artikel!

[tsboard]

Zum Thema lange Kompilierzeiten scheint mir der folgende Kommentar hilfreich zu sein, daher füge ich ihn hier hinzu: (von pr4wl)

Wenn Rust analyzer bei jeder Änderung eine lange Neukompilierung durchführt, liegt das wahrscheinlich daran, dass sich die beim Bauen der Anwendung verwendeten Features oder Umgebungsvariablen unterscheiden. Standardmäßig verwendet RA dasselbe Zielverzeichnis wie cargo build, um Build-Artefakte zu speichern. Wenn dabei Builds ausgeführt werden, die nicht miteinander kompatibel sind, wird immer wieder ein vollständiger Build angestoßen.

Dieses Problem tritt besonders häufig bei Bevy auf, wenn im Build das Feature bevy/dynamic_linking verwendet wird, in Rust analyzer jedoch nicht.

Die einfachste Lösung ist, RA anzuweisen, ein anderes Zielverzeichnis zu verwenden. Weitere Details dazu finden sich unter rust-analyzer.cargo.targetDir.

Eine weitere Lösung besteht darin, alle Features und Umgebungsvariablen identisch zu setzen, sodass die Build-Artefakte gegenseitig wiederverwendet werden können. Das kann allerdings knifflig sein.