Der Kern von Rust

• Rust ist eine Sprache, in der verschiedene Konzepte eng miteinander verflochten sind; selbst zum Verständnis eines einfachen Programms muss man viele Elemente gleichzeitig lernen
• Funktionen, Generics, Enums, Pattern Matching, Traits, Referenzen, Ownership, Send/Sync, Iterator usw. sind allesamt zentrale Elemente, die auf ihr Zusammenspiel hin entworfen wurden
• Im Vergleich zu JavaScript kann man in JS bereits mit dem Verständnis einiger weniger Konzepte Code schreiben, während man in Rust erst mit dem Verständnis des Gesamtkontexts der Sprache sinnvoll Code verfassen kann
• Diese Komplexität von Rust erhöht zwar die Lernhürde, bietet zugleich aber Sicherheit und Konsistenz und beeinflusst maßgeblich die Art, wie Code entworfen wird
• Diese sprachliche Verzahnung macht Rust besonders, und die Vision eines „kleineren Rust“ lenkt den Blick erneut auf eine präzise verzahnte Sprachphilosophie

---

Die Schwierigkeit, Rust zu lernen

• Obwohl Rust eine hohe Einstiegshürde hat, haben viele Menschen zu Dokumentation, APIs und verbesserten Diagnosen beigetragen
• Zu den grundlegenden Konzepten gehören Funktionen als First-Class-Objekte, Enums, Pattern Matching, Generics, Traits, Referenzen, Borrow Checker, Concurrency-Sicherheit und Iteratoren
• Diese Konzepte hängen voneinander ab und sind miteinander verflochten, weshalb sie sich schwer einzeln lernen lassen; auch die Standardbibliothek nutzt die meisten dieser Funktionen
• Selbst um rund 20 Zeilen Rust-Code zu verstehen, muss man zugleich mehrere Elemente erfassen: funktionale Paradigmen, Result und Fehlerbehandlung, generische Typen, Enums, Iteratoren usw.

Vergleich von Rust und JavaScript

• Wenn man dasselbe Programm zur Erkennung von Dateiänderungen in Rust und JS schreibt, sind in Rust zahlreiche Sprachkonzepte miteinander verflochten
• In JS reicht es grundsätzlich aus, Funktionen und den Umgang mit null zu verstehen, um funktionsfähigen Code zu schreiben
• Das bedeutet nicht einfach, dass Rust schwieriger ist, sondern zeigt, dass Rust eine Sprache ist, deren Design ein strukturelles Verständnis des Ganzen erfordert

Rusts miteinander verzahntes Design

• Der Kern von Rust ist die Verbindung organisch entworfener Funktionen
  • Enums sind ohne Pattern Matching unhandlich, und Pattern Matching ist ohne Enums ebenfalls eingeschränkt
  • Result und Iterator lassen sich ohne Generics nicht implementieren
  • Die Konzepte Send/Sync und die Einschränkungen von println lassen sich nur mit Traits sicher ausdrücken
  • Der Borrow Checker gewährleistet Send/Sync-Sicherheit durch die Analyse dessen, was Closures erfassen
• Diese gegenseitige Verzahnung macht Rust nicht bloß zu einer Sammlung von Features, sondern zu einem integrierten Sprachsystem

Die Vision eines kleineren Rust

• 2019 erwähnte without.boats „Smaller Rust“ und diskutierte die Möglichkeit eines kleinen, verfeinerten Rust
• Heute ist Rust deutlich größer geworden, doch das Konzept eines kleineren Rust erinnert weiterhin an das Wesen eines präzise ineinandergreifenden Sprachdesigns
• Rusts Reiz liegt darin, dass sprachliche Elemente zwar unabhängig voneinander sind, in ihrer Kombination jedoch starke Ausdruckskraft und Sicherheit bieten

Fazit

• Rust ist schwer zu lernen, aber die Konsistenz und Integration seiner miteinander verflochtenen Konzepte sind eine große Stärke
• Dank dieser Struktur bringt Rust Entwickler dazu, Code nicht einfach nur zu schreiben, sondern eine Denkweise zu entwickeln, die Sicherheit und Performance zugleich berücksichtigt
• Das Wesen von Rust liegt in einer „kleinen, präzise gestalteten Kernsprache“, und diese Philosophie bleibt auch im heutigen, erweiterten Rust wichtig

[GN⁺]

Hacker-News-Kommentare

• Es hat eine gewisse Ironie, dass selbst in einem „einfachen“ JS-Programm Bugs stecken. In der fs.watch-Dokumentation steht ausdrücklich, dass man im Callback unbedingt prüfen muss, ob filename null sein kann. In Rust würde diese Tatsache im Typsystem abgebildet und zur Behandlung zwingen, während man in JS leicht schlampigen Code schreiben kann. Zugehörige Doku
  • Wenn man TypeScript verwendet, wird die null-Prüfung erzwungen. Ich finde, das ist ein gutes Beispiel dafür, dass TS in JS eine relativ reibungsarme Stufe darstellt, die der Korrektheit von Rust etwas näher kommt
  • Es gibt noch einen weiteren Bug: for path in paths müsste for (const path of paths) heißen. JS wirft ohne Klammern zwar sofort einen Fehler, aber der Unterschied zwischen in und of ist, dass über Indizes des Iterables statt über die Werte iteriert wird, sodass am Ende tatsächlich der Index als String in das erste Argument von fs.watch gelangt. Selbst TypeScript erkennt diesen Fehler womöglich nicht
  • Wie schon angemerkt wurde, ist bereits die Schleifensyntax selbst falsch, und das merkt man sofort, wenn man es einfach ausführt. Daher ist es vermutlich sinnvoller anzunehmen, dass der Autor diesen JS-Code nicht besonders sorgfältig geschrieben hat und er für den eigentlichen Punkt nicht viel Bedeutung hatte
  • Vielleicht habe ich etwas übersehen, aber ich frage mich, woher kind kommt. In console.log("${kind} ${filename}") müsste es eigentlich eventType (ein String) statt kind sein
• Ich möchte auf eine Kleinigkeit hinweisen. println in Rust kann nur Typen ausgeben, die das Display- oder Debug-Trait implementieren. Deshalb kann Path nicht direkt ausgegeben werden. Nicht jedes OS speichert Pfade in UTF-8, und Rusts String-Typen sind alle UTF-8. Das heißt, die Ausgabe eines Path kann verlustbehaftet sein. Path liefert über die Methode display einen Typ zurück, der Display implementiert. Rust hat das im Typsystem verankert, während sich in JS/TS kaum klar ausdrücken lässt, dass interne Strings UTF-16 sind, und man für nicht-Unicode-Pfade eigentlich direkt TextEncoder/Decoder verwenden muss, um korrekt damit umzugehen. Aus früherer Erfahrung weiß ich: Wenn ein Server Text in Shift_JIS liefert und man ihn mit response.text() liest, bekommt man zur Laufzeit nur einen leeren String zurück. Wenn man mit Encoding-Problemen nicht vertraut ist, kann man in so einer Situation beim Debuggen locker mehrere Tage verlieren. Außerdem enthält das JS-Beispiel Bugs und Syntaxfehler, die im Rust-Code nicht vorhanden sind (in der Schleife braucht man for-of statt for-in). Man kann bei diesem Beispiel auch nicht wirklich davon sprechen, dass nur „First-Class Functions“ verwendet werden; man braucht wie in Rust auch ein Verständnis für Iteratoren, und es wird CommonJS verwendet. Außerdem muss man async/await, Promises und Top-Level-await neu lernen, und Top-Level-await wird erst seit Kurzem in einigen Laufzeiten einschließlich Node unterstützt. In manchen JS-Engines (z. B. Hermes von React Native) wird es immer noch nicht unterstützt

  • Genau deshalb benutze ich weiterhin Rust. Das Beispiel ist nur eines von vielen, aber solche kleinen Probleme und Fallstricke liegen in anderen Sprachen überall herum. Sie treten vielleicht nicht einzeln auf, aber über den gesamten Lebenszyklus eines Programms hinweg summieren sie sich, und dann springen einem ständig seltsame Bugs entgegen, die man immer weiter suchen muss. In Rust passiert das nicht. Das Typsystem blockiert im Vorfeld absurd viele Fälle. In der Praxis ist es so: Wenn man Software in Rust fertig implementiert und veröffentlicht hat, fügt man höchstens gelegentlich Features hinzu, und der typische Aufwand für allgemeine Bugfixes verschwindet fast völlig. Natürlich kann es überall logische Fehler geben, aber weil Probleme aus dummen Typ-/Struktur-Mismatches von vornherein ausgeschlossen werden, ist Produktivität und Wartbarkeit eine völlig andere Erfahrung als in anderen Sprachen

  • Ich habe persönlich den Eindruck, dass es in JS/TS nicht viele Entwickler gibt, die Thenables/Promises und async/await wirklich richtig verstehen. Ich habe auch so etwas gesehen:

    var fn = async (param) => new Promise((res, rej) => {
      fooLibraryCall(param).then(res).catch(rej);
    });
    

    Da wird ein Wrapper in Callback-Form einfach noch einmal in ein Promise gepackt und dann in einer async-Funktion erneut verwendet. Jedes Mal tut mir dabei das Herz weh. Solchen Code sehe ich tatsächlich überall. Und wenn man dann noch Modul-Imports, asynchrone import(), Transpiling, Code-Splitting usw. dazunimmt, wird es wirklich komplex

• Ich denke, das Bjarne-Zitat ist in Wahrheit ein Sales-Pitch, um wiederholt zu rechtfertigen, dass C++ immer schlechter wird. Am Anfang mag es ehrlich gemeint gewesen sein, aber inzwischen ist es ein wiederkehrendes Muster. Die Struktur ist aus meiner Sicht so:
  1. „In C++ steckt eine kleinere und sauberere Sprache“
  2. Aber weil man diese Sprache nicht einfach als Subset herauslösen kann, heißt es erst einmal: Lasst uns zuerst ein Superset bauen und danach das Subset definieren
  3. Das Superset landet dann im neuen C++N+1. Die echte Diskussion über das Subset wird auf später verschoben, und das Ganze wiederholt sich
  4. C++N+1 wird noch komplexer, und so geht es ewig weiter Wer das wiederholt gesehen hat, versteht kaum noch, warum andere dabei bleiben. Am Ende kommt diese „kleinere und sauberere Sprache“ nie. Es ist immer wieder nur Schritt eins
  • Das erinnert mich an xkcd 927. Der C++-Standard wird jedes Mal noch komplizierter; es gibt gute Änderungen, aber sie passen nicht immer gut zu älteren Versionen, und der Quellcode wird mit der Zeit immer chaotischer. Ich betreue zwei OSS-Bibliotheken, benutze C++ aber inzwischen fast gar nicht mehr. In letzter Zeit frage ich mich oft, wie lange ich das noch durchhalte. Rust ist nach c++11/14/17/20 wirklich erfrischend. Allerdings ist auch Rust groß genug, wenn man das Ganze erfassen will. Was in diesem Beitrag angemerkt wurde, fühlt sich deshalb sehr treffend an. xkcd 927
• War sonst noch jemand sofort abgelenkt, als er den Shebang für ein selbst ausführbares Rust-Skript gesehen hat? Ich war ähnlich überrascht wie damals, als ich dasselbe bei Go entdeckt habe. Das wirkt ziemlich nützlich und dürfte für grundlegende Zwecke völlig ausreichen. Ich habe so etwas auch schon in Projekten gesehen, die Build-/Test-Pipelines mit Rust verwalten. Für solche Zwecke wäre das eine recht gute Alternative. Ich persönlich nutze aber meistens Deno+TS, sobald ich ein Skript brauche, das etwas über Bash hinausgeht. Mit JS arbeite ich am längsten (seit 28 Jahren), danach kommt C# mit 24 Jahren. Node benutze ich seit den frühen Tagen. Deno ist beim Teilen und Zentralisieren von Paketen einfacher zu verwalten als Node oder Python. Cargo-Frontmatter funktioniert auf ähnliche Weise
  • Ich bin die Person, die die Integration von Scripts in Cargo selbst entworfen und implementiert hat (es gab in der Zwischenzeit viele Drittanbieter-Implementierungen). Es freut mich sehr, echte Anwendungsfälle zu sehen und zu wissen, dass das hier erwähnt wurde. Siehe auch die Dokumentation. Es gab langwierige Diskussionen darüber, welche Form geeignet ist, wie sich das mit der Sprache verzahnen soll und wie groß der Umfang der ersten Veröffentlichung sein sollte. Im Moment stehen noch Abschlussarbeiten wie ein Style Guide und Updates für die Rust-Referenz an; die großen verbleibenden Punkte betreffen Details rund um rustfmt, rust-analyzer, Bugfixes in rustc und besseres Error Reporting in Cargo. Ich selbst schreibe jeden Tag Reproduktionsskripte für Issues mit Cargo Script
  • Ich wurde tatsächlich dadurch abgelenkt, dass ich angefangen habe, nach dem Funktionsschlüsselwort -Zscript zu suchen und dazu zu recherchieren. Das läuft seit 2023, und es gibt Open Issues, die schon fast fertig wirken. Im ZomboDB-Repository habe ich ebenfalls gesehen, dass die Build-Pipeline mit Rust abgewickelt wird, aber den vollständigen Kontext habe ich nicht ganz verstanden. Ich möchte noch erwähnen, wie nützlich Cargo-Frontmatter für die Portabilität von Skripten ist. Man muss nur eine Datei teilen und kann dann, anders als bei Python oder Node.js, Abhängigkeiten sofort holen und verwenden, ohne zusätzliche Installation oder Initialisierung
  • Es hieß, dass man dasselbe auch in Go machen könne; ich wäre an einer genaueren Erklärung interessiert. Falls dieser Link gemeint ist, interessiert mich das ebenfalls
  • Obwohl ich lange JS und C# verwendet habe, würde ich im Jahr 2025 kein System mehr aus solchen Gründen auswählen. In den letzten 20 Jahren sind wirklich sehr viele Dinge deutlich besser geworden
  • Das ist einfach eine grundlegende Unix-Funktion. Eine Datei, die mit #!/some/path beginnt, wird von der Shell einfach mit dem angegebenen Kommando ausgeführt, wobei der gesamte Dateiinhalt über stdin übergeben wird
• Ich frage mich, was genau mit der Aussage gemeint ist, dass in Rust „eine kleinere und sauberere Sprache im Inneren entsteht“. Dem Text nach müssten Referenzen, Lifetimes, Traits, Enums usw. weiterhin vorhanden sein, damit es funktioniert, und dann wäre es kaum etwas anderes als Rust selbst. Im letzten Teil gibt es zwei Hinweise, nämlich das „Rust, das ich schreiben will“ und das „Rust der Vergangenheit“, aber beides überzeugt mich nicht besonders. Ich habe auch withoutboats’ „Notes on a smaller Rust“ gelesen, doch die Designziele unterscheiden sich bereits von Rust, sodass es weniger darum geht, Rust zu werden, sondern eher darum, welche Lehren man aus Rust ziehen kann, wenn man eine neue Sprache entwirft. Es ist keine Sprache, die Rust werden will, sondern eher ein Beispiel für eine Sprache mit stärker „mainstream“-gerechten Anforderungen (z. B. GC, vereinfachtes Kompilieren/Syntax usw.). Zweitens heißt es dort auch: „Die Sprache, in die ich mich 2018 beim ersten Lernen verliebt habe, ist dieses ‚kleinere Rust‘“, aber tatsächlich hat sich Rust seit 2018 im Kern nicht so stark verändert. Der Großteil sind Verbesserungen bei syntaktischer Flexibilität wie Editions; echte große Ausnahmen sind async und const. Wenn das gemeint ist, hätte man meiner Meinung nach einfach direkt sagen sollen: „Rust vor async und const war kleiner und sauberer.“ Im Haupttext wird das leider nicht so unmittelbar ausgesprochen
  • Wenn man von einem „kleineren und saubereren Rust“ spricht, fällt mir als Beispiel die Sprache Austral ein
  • Es gibt auch die Behauptung, dass eine einfachere (kleinere) Sprache möglich ist, die die Kernideen von Rust beibehält. Man könnte zum Beispiel das Copy-Trait, Reborrowing, Deref-Coercion, automatisches into_iter in Schleifen, automatische drop-Aufrufe am Ende eines Scopes (man könnte das auch explizit aufrufen oder den Compiler Fehler werfen lassen), das implizite :Sized bei Trait Bounds, Lifetime-Elision, Match-Ergonomics und allerlei weitere Automatisierungen/Bequemlichkeiten entfernen, und dann bekäme man ein wirklich mechanisch einfacheres Rust. Allerdings wäre eine solche Sprache im Alltag sehr unbequem zu benutzen. Ironischerweise wurden diese Dinge in Wahrheit für Anfänger entworfen
  • Ich habe das wirklich sehr sorgfältig gelesen. Tatsächlich war genau meine Absicht zu sagen, dass Rust vor der Einführung von async und const kleiner und sauberer war. Dass ich es nicht direkter formuliert habe, liegt daran, dass ich mit Leuten befreundet bin, die an diesen Features gearbeitet haben. Matklad hat das auf lobste.rs sehr gut ausgedrückt: Rust von 2015 war vollständiger und konsistenter, aber Rusts Vision war nie vollkommene Konsistenz (coherence), sondern eine Sprache zu werden, die in der Industrie nützlich ist
• Ich bin vielleicht voreingenommen, aber ich halte Rust für die Sprache, die der Perfektion am nächsten kommt. Der Borrow Checker ist lästig, aber notwendig. Hätte man denselben fehlerhaften Code in C geschrieben, wäre das Programm zur Laufzeit kollabiert — und dann müsste man den Bug am Ende trotzdem beheben. Der Unterschied ist, dass Rust einen zwingt, den Fehler vor dem Kompilieren zu beheben, während man ihn in C mitten in der Nacht im Fehlerfall ausbaden muss. Ich glaube nicht, dass Rust schwer ist; es verlangt eher einen Wechsel der Denkweise. Man braucht einen Paradigmenwechsel hin zu sicherem und sicherheitsrelevant robustem Code. Veränderungen sind meistens unbequem, und ich denke, genau das ist die eigentliche Wurzel der Abneigung gegen Rust
  • Rust ist weit von Perfektion entfernt
    • Ich finde, der Compiler kann bei der Anwendung und Reihenfolge von Deref zu frei entscheiden. .into() und das From-Trait behandeln Typkonvertierungen zu implizit. Auch in der Standardbibliothek gibt es viele dieser „Bequemlichkeits“-Funktionen. Am Ende wird der Typ eines Objekts undeutlich, und es wird schwierig, Funktionsaufrufe mit ihren Implementierungen zu verknüpfen (auch wenn eine IDE dabei etwas hilft)
    • Implizite Rückgaben verschleiern den Programmfluss und laden zu Fehlern ein. Auch der Fragezeichen-Operator gefällt mir nicht besonders
    • Das Rust-Ökosystem zerschneidet selbst kleine Module so stark, dass man für etwas Nützliches gleich Hunderte von Dependencies braucht. Für stabile Builds muss man sie jeweils separat pflegen und vendoren, und das ist wirklich unbequem
    • Async Rust ist derzeit pures Chaos
  • Mein Hauptproblem ist weniger der Borrow Checker selbst als vielmehr, dass Rust als Ganzes zu groß geworden ist. Für Leute, die das raue, unvollständige Rust von 2018 mochten (mich eingeschlossen), ist das heutige Rust nicht mehr besonders attraktiv. Natürlich ist es extrem mächtig, wenn man es beherrscht, aber man fragt sich schon, ob der Aufwand das wirklich wert ist. Wenn ich 2025 eine Alternative zu C/C++ wählen müsste, würde ich wahrscheinlich Zig nehmen (die einzige Ausnahme wären Postgres-Arbeiten; das pgrx-Ökosystem ist wirklich einzigartig). Trotzdem ist fast alles besser, als mit C zu arbeiten
• Ich denke nicht, dass man Rust als erste Programmiersprache empfehlen sollte. Eine erste Sprache zu lernen ist ohnehin schwer, und bei Rust ist es wegen der Compilerfehler oft schon schwierig, überhaupt etwas laufen zu sehen, bevor der Code vollständig korrekt ist. Das ist zu frustrierend, und viele würden schnell aufgeben. Ich würde eher raten, mit Python, JavaScript oder Lua zu beginnen, schnell etwas wie ein Spiel zu bauen und iterativ zu lernen
  • Meine Erfahrung ist anders. Ein ML-Ingenieur bei uns kannte nur Python, wollte aber zu unserer Rust-Codebasis beitragen. Ich habe ihm ungefähr eine Stunde lang die Grundlagen erklärt, und er hat sich sofort gut zurechtgefunden; seine Produktivität stieg direkt an. Tatsächlich kann es sehr viel Zeit kosten, bei einem Spiel nachzuverfolgen, warum es abstürzt, nur weil man einen String an eine Zahlenfunktion übergeben hat. In Rust markiert der Compiler einfach: „Hier ist ein String, hier müsste ein int stehen“, und das Debugging ist deutlich schneller erledigt. Man verbringt nicht den ganzen Tag mit Compilerfehlern, sondern spart sich eine Woche Leid mit Laufzeitfehlern
  • Ich bin die Person aus dem Zitat ganz oben im Blog. Ich habe Rust bereits mehr als 400 Menschen als erste Sprache beigebracht, und die Behauptungen in diesem Thread finde ich sehr interessant. Durch langjährige direkte Erfahrung habe ich genug Evidenz gesammelt, dass das nicht nur theoretisch möglich ist, sondern ziemlich gut funktioniert
  • Ich bin noch nicht ganz überzeugt. Ich würde gern sehen, wie ein guter Pädagoge Rust als erste Sprache unterrichtet. Die Generationen ändern sich, und an Universitäten wird heute oft Python verwendet, aber theoretisch könnte Rust als erste Sprache das Niveau einer gesamten Kohorte heben (auch wenn die Durchfallquote möglicherweise so hoch wäre, dass es administrativ problematisch würde; umgekehrt könnten fortgeschrittene Studierende dadurch mehr lernen). Dinge wie Move-Assignment oder die Bedeutung des Schlüsselworts const in Rust könnten sogar helfen, sich später das Verlernen schlechter Gewohnheiten aus traditionellen Sprachen zu ersparen
  • Normalerweise würde ich empfehlen, statische Typisierung als erste Sprache zu vermeiden. Ich mag statische Typisierung zwar auch, aber für Anfänger sorgt sie oft nur für zusätzliche Verwirrung. Compilerfehler sind häufig kontrafaktisch, und Meldungen wie „Der Compiler konnte nicht beweisen, dass dies nicht none ist“ fühlen sich viel schwieriger an als ein Laufzeitabsturz in einem Testfall, dessen Stelle man sofort findet. Wenn man selbst Zeile für Zeile Werte ausgibt und so Fehler sucht, lässt sich vieles schnell lösen; an kryptischen Compilerfehlern kann man dagegen wirklich lange hängenbleiben
  • Rust ist keine schlechte Sprache, wenn man alles auf einmal aufnehmen kann. Das Problem ist nur, dass niemand eine Sprache auf diese Weise lernt, und wenn man die Hauptkonzepte nicht ausreichend versteht, gerät man in Rust immer wieder in Trial-and-Error. Außerdem gibt es dort am Ende viele Konzepte, die man in anderen Sprachen nie gelernt hat, sodass ein Wechsel in eine neue Sprache erneut frustrierend werden kann
• Das Nächste, was ich bisher an „einfachem Rust“ gesehen habe, ist Gleam. Es scheint stark von Rust inspiriert zu sein
  • Dass Gleam von Rust inspiriert sei, ist ein Missverständnis. Der Autor sagt das nicht offiziell. Der Compiler ist zwar in Rust geschrieben, aber Gleam unterscheidet sich in Paradigma und Ziel-Laufzeit grundlegend und ist kein Rust-Ersatz
  • Wenn man einen anderen Stil von „simple rust“ will, würde ich empfehlen, sich F# anzusehen
  • Auf der Hauptseite von Gleam stehen Botschaften zu Black Rights, Trans-Rechten und Anti-Nazismus; deshalb interessiert mich diese Sprache überhaupt nicht
  • Ich frage mich, ob man mit Gleam 3D machen kann
• Mich hat gestört, dass „nicht erklärt wird, was das Rust-Programm eigentlich tut“. Es gibt eine enorme Menge technischer Erklärung, aber keine Zusammenfassung dessen, was das Programm tatsächlich macht. In Wirklichkeit überwacht es nur Dateiänderungen und druckt sie aus. Gerade daran zeigt sich die Schwierigkeit der Sprache: Selbst für eine so einfache Aufgabe wird die Implementierung in Rust komplex, sodass man sich um interne Details kümmern muss, die mit dem eigentlichen Problem nichts zu tun haben. Ich sehe diese Komplexität sowohl als echte Herausforderung als auch als eine selbst geschaffene Hürde
  • Andere Sprachen haben genau dasselbe Problem, aber Rust hilft dabei, sich frühzeitig darum zu kümmern. Nicht jeder Dateiname ist sinnvoll ausgebbar, und die meisten Sprachen wälzen diesen Teil einfach auf den Benutzer ab. Rust markiert Fehler/Misserfolge dagegen klar im Rückgabetyp, während andere Sprachen dafür Mechanismen wie Exception-Handling brauchen. Was auf den ersten Blick einfach wirkt, könnte in Rust in Wahrheit sogar intuitiver sein
  • Auch die Implementierung ist für eine Hochleistungssprache in Wirklichkeit sehr einfach. Sie passt komplett auf eine Seite. Ist das nicht schon ein hinreichend einfaches Beispiel?
  • Einfache Erklärung = einfache Implementierung gilt nicht immer. XKCD 1425 zeigt ein gutes Beispiel dafür. (Z. B. ist leicht zu prüfen, ob ein Foto in einem Nationalpark aufgenommen wurde, aber um zu erkennen, ob es ein Vogelfoto ist, braucht man ein Forschungsteam.) xkcd 1425
• Ich finde, Rust ist semantisch ziemlich konsistent und kohärent. Im Vergleich zu anderen Sprachen gibt es weniger Syntaxzucker und ähnliche Zusätze, daher wirkt es intuitiver. Fast alle Interfaces folgen gewöhnlich dem Muster des mem-Moduls; wenn man die Struktur der Interfaces wirklich verstehen will, ist std::mem ein guter Startpunkt