Leitfaden zum Abflachen der Lernkurve von Rust

• Rust ist eine Sprache, die ein völlig neues Denkmodell verlangt, und die innere Haltung hat großen Einfluss auf die Lerngeschwindigkeit
• Der Schlüssel ist, sich mit dem Compiler anzufreunden; wichtig ist nicht nur, Fehlermeldungen zu beheben, sondern die Gründe dahinter zu verstehen
• Am Anfang ist es sinnvoll, clone(), unwrap usw. aktiv zu nutzen, klein anzufangen und schrittweise zu refaktorieren
• Man sollte viel Code von Hand schreiben und durch Fehler und Versuch-und-Irrtum Intuition und Muskelgedächtnis aufbauen
• Rust folgt einer typzentrierten Entwicklungsphilosophie; daher ist es wichtig, die Dokumentation sorgfältig zu lesen und das Modellieren mit Typen zu üben

---

Flattening Rust's Learning Curve

Rust gilt als schwer zu erlernende Sprache, aber dieser Beitrag gibt auf Basis der Erfahrungen des Autors konkrete Ratschläge zu Haltung und Vorgehensweise, um Rust effektiver zu lernen

Let Your Guard Down

• Rust verlangt ein anderes mentales Modell als bisherige Sprachen
• Es kommt vor, dass Anfänger schneller lernen als Fortgeschrittene → Haltung und Offenheit sind entscheidend
• Den Borrow Checker sollte man nicht als Feind sehen, sondern als Mitautor; man sollte sich bemühen, Fehlermeldungen wirklich zu verstehen
• Wichtig ist die Bereitschaft, tief zu verstehen, warum der Compiler Lifetime-Parameter verlangt
• Wenn Code unschön und komplex wirkt, kann das auf ein falsches Design hindeuten; das sollte als Anstoß dienen, nach einem besseren Weg zu suchen
• Rusts Ausführlichkeit (verbosity) hilft bei großen Anwendungen und ist vorteilhaft fürs Refactoring
• clippy-Lints sollte man unbedingt von Anfang an vollständig aktivieren und nutzen

Baby Steps

• Am Anfang kann man String, clone(), unwrap großzügig verwenden und später refaktorieren
• Statt komplexer Method Chaining lieber zuerst mit einfachen if- und match-Anweisungen beginnen
• Asynchronität (async) sollte man in der ersten Woche möglichst meiden
• Zum Lernen kleine Codefragmente im Rust Playground ausprobieren
• Für jedes Konzept eine eigene main.rs-Datei anlegen und den meisten Code mit dem Gedanken schreiben, ihn später wegzuwerfen

Be Accurate

• In Rust ist Genauigkeit eine Überlebensbedingung
• Tippfehler oder kleine Fehler führen sofort zu Compilerfehlern, daher ist Sorgfalt nötig
• Es hilft, sich anzugewöhnen, & und mut automatisch mitzudenken
• Streaming-Videos von Entwicklern wie Tsoding sind gutes Referenzmaterial

Don’t Cheat

• Wer sich auf LLMs oder Code-Autovervollständigung verlässt, lernt langsamer
• Wichtig ist, selbst von Hand zu tippen und bei Unklarheiten in der Dokumentation nachzuschlagen
• Nicht im Auto-Pilot-Modus programmieren
• Fehler akzeptieren und dadurch verstehen, wie der Compiler arbeitet
• Empfehlenswert ist auch, vor dem Ausführen des Codes vorherzusagen, ob er kompilieren wird
• Ebenso wichtig ist die Gewohnheit, den Code anderer zu lesen und zu analysieren
• Während des Lernens sollte man externe Crates sparsam verwenden; nur serde und anyhow sind als Ausnahmen vertretbar

Build Good Intuitions

• Die Konzepte lifetime und ownership lassen sich visuell oft besser verstehen
• Empfehlenswert ist, sich anzugewöhnen, mit Tools wie excalidraw Datenflüsse und Architekturen selbst zu skizzieren
• Viele hervorragende Ingenieure und Mathematiker nutzen Visualisierungswerkzeuge sehr effektiv

Build On Top Of What You Already Know

• Rust funktioniert auch bei vertrauten Konzepten anders (z. B. mut, Move von Werten usw.)
• Dennoch ist Lernen durch Vergleiche mit bestehenden Sprachen nützlich

Beispiele:

• Trait → ähnlich wie ein Interface, aber nicht dasselbe
• Struct → wirkt wie eine Klasse ohne Vererbung
• Closure → ähnlich wie ein Lambda
• Module → Namespace
• Borrow → Zeiger mit einem einzelnen Besitzer
• Option → Maybe monad
• Enum → Algebraic data type

• Rosetta Code ist nützlich, um Code zwischen mehreren Sprachen vergleichend zu lernen
• Es ist auch effektiv, Code aus einer vertrauten Sprache nach Rust zu portieren
• Sinnvoll ist außerdem die Übung, darüber nachzudenken, wie sprachspezifische Idiome wie Listensyntax oder Schleifen in Rust ausgedrückt werden

Don’t Guess

• Rust ist eine Sprache, in der Raten nicht funktioniert
• Man sollte darüber nachdenken, warum man Code wie "hello".to_string() schreiben muss
• Fehlermeldungen sind äußerst lehrreich, daher sollte man die darin verborgenen Hinweise nie ignorieren
• Gerade bei Borrow-Checker-Fehlern sollte man den Datenfluss von Hand nachverfolgen und analysieren

Lean on Type-Driven Development

• Rust ist eine typgetriebene Sprache
• Aus Funktionssignaturen und Typdefinitionen lässt sich viel Information gewinnen
• Man sollte häufig die Dokumentation und den Quellcode der Standardbibliothek lesen
• Wer zuerst Typen entwirft und dann den passenden Code schreibt, kann präzisere und besser wiederverwendbare Strukturen bauen
• Wenn man Invarianten mit Typen ausdrückt, kompiliert fehlerhafter Code von vornherein nicht

Invest Time In Finding Good Learning Resources

• Es gibt noch nicht sehr viele gute Rust-Lernmaterialien, deshalb spart es Zeit, früh Ressourcen zu finden, die zur eigenen Lernweise passen
• Lernwerkzeuge wie Rustlings gefallen je nach Person mehr oder weniger
• Aufgabenorientierte Materialien wie Advent of Code oder Project Euler können geeigneter sein
• YouTube-Videos sollte man eher zur Unterhaltung als als Informationsquelle nutzen
• Am effektivsten ist es, ein Buch zu kaufen, offline zu lesen und den Code selbst zu schreiben
• Wenn möglich, kann Unterricht oder Coaching durch Experten langfristig sehr viel Zeit sparen

Find A Coding Buddy

• Es ist auch hilfreich, den Code eines starken Kollegen wie ein Schatten zu begleiten und zu beobachten
• In Rust-Foren, auf Mastodon usw. kann man um Code-Reviews bitten oder selbst Reviews schreiben und dadurch besser werden

Explain Rust Code To Non-Rust Developers

• Auch das Erklären gegenüber Menschen ohne Rust-Kenntnisse hilft beim Lernen
• Empfehlenswert ist außerdem, zu nicht mehr gepflegtem Code in Open-Source-Projekten beizutragen
• Hilfreich ist es, ein Glossar zu erstellen, das Rust-Begriffe auf die Sprache der eigenen Fachdomäne abbildet

Believe In The Long-Term Benefit

• Rust ist eine Sprache für langfristige Qualität eher als für kurzfristige Produktivität
• Man wird nicht über Nacht zum Experten, aber schon ein Monat konzentriertes Lernen bringt viel
• Rust ist eine Day-2-Sprache: Der erste Tag ist hart, aber bei kontinuierlicher Nutzung steigt ihr Wert
• Um erfolgreich zu sein, sollte man nicht nur für den Lebenslauf lernen, sondern Programmieren selbst wirklich mögen

[aer0700]

Früher habe ich einmal Code, den ich zu Lernzwecken in C geschrieben hatte, in Rust neu geschrieben, und ich erinnere mich noch daran, wie quälend der Umgang mit Zeigern war ... Dinge wie Rc oder RefCell bekomme ich gedanklich bis heute nicht so richtig sauber sortiert ...

[q8840]

Nachdem ich die grundlegende Dokumentation und das Nomicon der Reihe nach jeweils nur einmal gelesen hatte, bin ich bei Rust kein einziges Mal hängen geblieben, daher frage ich mich, ob die Lernkurve wirklich so steil ist.

[freedomzero]

Oh, wenn man erst mal auf den Geschmack von unwrap und clone kommt, wird man später wegen Ownership ziemlich leiden ;_;

[GN⁺]

Hacker-News-Kommentare

• Fühlt sich an wie beim Lesen von „A Discipline of Programming“. Dijkstras moralisierende Art zu erklären war früher wohl wirklich nötig, weil die Leute die Programmierkonzepte selbst nicht verstanden. Erklärungen zu Ownership in Rust sind meist viel zu weitschweifig. Die Kernidee ist fast immer vorhanden, aber unter den Beispielen versteckt: In Rust hat jedes Datenobjekt genau einen Besitzer. Dieses Eigentum kann übertragen werden, aber immer nur so, dass es genau einen Besitzer gibt. Wenn man mehrere Besitzer braucht, muss der eigentliche Besitzer eine referenzgezählte Zelle sein. Diese Zelle lässt sich klonen. Wenn der Besitzer verschwindet, verschwindet auch alles, was ihm gehört. Mit ref kann man sich vorübergehend Zugriff auf ein Datenobjekt leihen. Ownership und Referenzen sind klar verschieden. Referenzen können weitergegeben und gespeichert werden, dürfen aber nicht länger leben als das Objekt selbst. Sonst entsteht ein Fehler wegen eines „dangling pointer“. Diese Regeln werden zur Compile-Zeit strikt vom Borrow Checker erzwungen. Das ist Rusts Ownership-Modell. Wenn man es verstanden hat, laufen die Details letztlich auf diese Regeln hinaus.

  • Vielleicht geht das nur mir so, aber solchen konzeptionellen Erklärungen kann ich schwer folgen. Bei Kapselung war es ähnlich. Es heißt nur, Informationen würden verborgen, aber nicht konkret, wie oder warum. Zum Beispiel verstehe ich in Rust nicht genau, wer eigentlich der Besitzer ist. Ist es ein Stack-Frame? Wegen der LIFO-Struktur frage ich mich, warum Ownership an den Callee übergeht — der Stack des Callee verschwindet doch zuerst, also wäre das nicht ungefährlich? Geht es nur darum, Objekte zur Optimierung früher freizugeben? Falls der Besitzer kein Stack-Frame ist, weiß ich auch nicht, was er dann ist. Ich verstehe auch nicht, warum es nur eine mutable Referenz geben darf. In einer Single-Thread-Umgebung scheint es doch egal zu sein, ob zwei Funktionen mutable Referenzen bekommen, solange nicht vor Ende der einen die andere startet. Wenn es nur in Multi-Thread-Umgebungen problematisch wird, könnte man dann nicht erst dort einen Fehler werfen? Wegen solcher Fragen breche ich das Lernen von Rust immer wieder ab.

  • Das ist keine Erklärung von Ownership, sondern eine motivierende Beschreibung. Das Schwierigste und Entscheidendste ist, komplex verschachtelte Lifetimes in Funktionssignaturen lesen zu können und Compiler-Fehler bei solchen Funktionsaufrufen zu verstehen und zu beheben.

  • Eine Zusammenfassung zu bauen, die auf Leute richtig und vollständig wirkt, die diese Konzepte schon kennen, ist viel leichter, als sie jemandem zu erklären, der sie zum ersten Mal lernt. Würde das jemand, der bisher nur call-by-sharing genutzt hat, auf Anhieb verstehen? Eher nicht.

  • Wer Rust nicht kennt und nur diese Zusammenfassung liest, wird danach nichts über Rust wissen. Man denkt dann nur: „Diese Sprache wirkt, als hätte der Compiler irgendeine Black Magic.“

  • Ownership und Borrowing als Konzepte sind leicht zu verstehen. Wirklich schwer wird Rust, weil Funktionssignaturen und echter Code sich gegenseitig beweisen müssen, dass Referenzen nicht länger leben als die Objekte. Nebenbei: Keine referenzierten Objekte im Typ zu speichern ist oft die bessere Wahl, weil das den Beweis weniger kompliziert macht.

  • Ich suche schon lange nach Texten darüber, wie Leute in den 60ern auf Assembler-Ebene mit System-/Applikationszustand umgegangen sind. Ich habe gehört, dass Sutherlands Sketchpad-Paper viele Details zu Datenstrukturen enthält, aber bisher nur Kapitel 2–3 gelesen.

  • Diese Erklärung ergibt für mich keinen Sinn. Ownership und Borrowing werden nicht klar definiert. Beides wirkt wie Terminologie auf Basis einer Metapher aus der Verwaltung von Finanzvermögen. Ich kenne Rust nicht gut, aber schon diese Wortwahl scheint das Verständnis zu erschweren. Metaphern sind oft ein zweischneidiges Schwert. Eine direktere Erklärung mit Speicherbegriffen wäre vermutlich hilfreicher.

  • Im Modell fehlt vollständig der wichtige Unterschied zwischen exklusivem und geteiltem (oder mutablem und immutablem) Borrowing. Rust hat viele Entscheidungen darüber getroffen, wie solche Borrows erlaubt werden, und das ist nicht intuitiv. Die no-aliasing-Regel stammt zum Beispiel nicht aus der Intuition, sondern aus dem Ziel der Funktionsoptimierung. Das Komplizierteste beim Borrowing ist, dass Compiler-Fehlermeldungen wegen der Lifetime-Elision-Regeln oft auf die falsche Stelle statt auf die eigentliche Ursache zeigen. Diese Elision-Regeln sind nicht intuitiv und wurden als Vereinfachung eingeführt.

  • Die von der Brown University überarbeitete Version des Rust Book erklärt den Borrow Checker wirklich gut.

  • Die Erklärung scheint unvollständig zu sein. Es fehlt zum Beispiel, was passiert, wenn die entleihende Seite verschwindet.

  • Da steht: „Der eigentliche Besitzer muss eine referenzgezählte Zelle sein“, aber das ist so erklärt, dass es nur Leute verstehen, die ohnehin schon wissen, was das ist.

  • Ich habe den Borrow Checker erst verstanden, nachdem ich meinen eigenen implementiert hatte.

  • Der zweite Punkt im zweiten Abschnitt ist massiv übertrieben. In der Praxis gibt es unzählige Fälle mit sicherem Code, den Rust trotzdem nicht kompiliert. Diese Komplexität ist entstanden, um die Grenzen dessen klarzumachen, was der Compiler beweisen kann.

• Rusts Ownership-Modell, Lifetimes, enum und Pattern Matching waren beim ersten Kontakt extrem einschüchternd. Beim ersten Versuch war ich sehr schnell überfordert, und beim zweiten wollte ich jede Zeile des Buchs lesen, bis mir die Geduld ausging. Gleichzeitig merkte ich, dass Rust eine Sprache ist, die tiefere Einsichten in Programmierung und Softwaredesign vermittelt. Erst beim dritten Versuch fing ich an, wirklich zu lernen, indem ich kleine Programme und Skripte, die ich vorher geschrieben hatte, im Rust-Stil neu schrieb. Dabei lernte ich auch idiomatisches Error Handling in Rust, Datendarstellung mit konsequenter Nutzung von Typen, Pattern Matching und mehr. Nach dieser Erfahrung bin ich überzeugt, dass Rust zu lernen eine der besten Entscheidungen meines Lebens als Programmierer war. Typen, Structs und enum im Voraus zu definieren und Funktionen auf Basis unveränderlicher Daten und Pattern Matching zu schreiben, wende ich inzwischen ganz natürlich auch in anderen Sprachen an.

  • Ähnliche Erfahrung. Erst beim dritten Anlauf begann es wirklich Klick zu machen, und ich konnte einige Programme effektiv schreiben. Auch mit langer Programmiererfahrung gibt es Dinge, für die man Wiederholung braucht. Früher brauchte ich zum Beispiel ebenfalls genau drei Anläufe, um Dagger, das Dependency-Injection-Framework im JVM-Ökosystem, zu verstehen. Vielleicht ist das bei mir einfach ein generelles Muster beim Lernen komplexer Dinge.

  • Das sieht man oft bei C++-Entwicklern, wenn sie zum ersten Mal Rust anfassen: Mit C++-Vorstellungen kämpft man ständig gegen den Borrow Checker. Wenn man die Rust-Konventionen wirklich lernt, bringt man vieles davon zurück nach C++ und schreibt robusteren Code — auch ohne Borrow Checker.

• Der Rat „Lies vor dem Kompilieren den ganzen Code sorgfältig durch und korrigiere Tippfehler“ wirkt auf mich seltsam. Der Rust-Compiler ist doch berühmt für sehr hilfreiche Fehlermeldungen. Warum sollte ich am Code sitzen und selbst Tippfehler suchen? Ich will, dass der Computer das für mich tut.

  • cargo fix behebt manche Probleme automatisch, aber eben nicht alle.

• Es gibt Ratschläge wie „Leiste keinen Widerstand“, „Wenn du lernen willst, leg deine Arroganz ab“, „Du musst kapitulieren“, „Widerstand ist zwecklos; je früher du es akzeptierst, desto weniger leidest du“ oder „Vergiss, was du weißt“. Da denke ich sofort, das telescreen-OS von Orwell sei wohl in Rust geschrieben.

  • Dem stimme ich zu. Mein größter Fehler beim Lernen von Rust war, es gewaltsam in ein objektorientiertes Paradigma pressen zu wollen. Als ich einfach akzeptierte, es so zu machen, wie Rust es will, lief es sofort viel besser.

• Rust hat für Einsteiger eine ziemlich hohe Hürde. Es ist sehr anders als andere Sprachen — absichtlich, aber genau das macht die Einstiegshürde aus. Die Syntax ist komplex und sehr kompakt, fast so, als hätte jemand mit dem Ellbogen auf die Tastatur gehauen. Ein einzelnes Zeichen kann die Bedeutung komplett ändern, und Verschachtelung kommt häufig vor. Viele Features sind ohne theoretischen Hintergrund schwer zu verstehen, was die Komplexität stark erhöht. Typensystem und Borrowing-Mechanismus sind die besten Beispiele. Für typische Python- oder JavaScript-Nutzer wirkt das fast wie eine Fremdsprache. Wir leben in einer Zeit, in der die meisten Programmierer faktisch keinen CS-Hintergrund auf Master-Niveau haben, deshalb scheint Rust dafür nicht passend. Und Makros machen alles noch komplizierter. Wenn man ihre Definition nicht kennt, ist schwer zu verstehen, was Code überhaupt bedeutet. In letzter Zeit hoffe ich allerdings, dass LLMs diese Hürden senken können. Ich spüre zwar noch nicht die Notwendigkeit, Rust zu lernen, aber dank LLMs wäre ich vielleicht irgendwann bereit, es noch einmal zu versuchen. Rust ist jedenfalls auf eine ganz eigene Weise schwer zu lernen.

  • Das Schwierigste beim Lernen von Rust waren für mich tatsächlich die Makros. Die Materialien, die ich benutzt habe, führten sie früh ein, ohne sie zu erklären, und das war verwirrend.

• Es scheint in jeder Situation bessere Optionen als Rust zu geben. Trotzdem bleibe ich offen. Vielleicht ergibt es Sinn, wenn Rust eines Tages wirklich verbreitet genug ist.

  • Wenn Rust noch immer genau für den Zweck entworfen wäre, für den es vor fast 20 Jahren ursprünglich gedacht war, dann wäre es die perfekte Sprache, um einen Browser von Grund auf neu zu bauen. Heute dominiert Rust in diesem Bereich bereits. Und das „unix“ des Sprachgründers hat die Welt nicht erobert, noch wurde es durch irgendein von jemandem gebautes Ladybird ersetzt.

• Wenn eine Sprache sogar Texte braucht, die Menschen erst davon überzeugen sollen, dass es sich lohnt, sie mühsam zu lernen, dann frage ich mich, ob das nicht schon auf ein Problem im Sprachdesign hindeutet. (Ich habe Rust nicht gelernt, also bitte nicht zu ernst nehmen.)

  • Deinen Kommentar kann ich nur als „Alles, was schwer ist, ist es nicht wert“ lesen. Alles hat Vor- und Nachteile. Heißt das allein wegen vorhandener Nachteile, dass es nicht einmal einen Versuch wert ist? Wenn jemand begeistert darüber schreibt, dass Harfe spielen schwer ist — wäre Harfe dann ein miserables Hobby?

  • Wenn man Senior-Entwickler wird, hat man die Lektionen, die Rust wichtig findet, oft wenigstens am Rand gesehen, aber nicht wirklich durchlebt. Viele denken: „Ich benutze schon eine Sprache mit Garbage Collection, was soll Rust mir also beibringen?“ In Wirklichkeit entsteht riesige Verwirrung, wenn Mutabilität und geteilte Referenzen ineinander greifen, weshalb man oft viele immutable Objekte einführt. Hat man dann immutable Objekte, fragt man sich wieder, wie man sie bequem transformieren kann, und am Ende kann das unhandlicher werden als mutable Objekte. Wenn man ausdrücken will: „Dieses Objekt hat Phasen, in denen es veränderbar ist, und Phasen, in denen es unveränderlich ist“, landet man letztlich beim Bedarf nach einem Borrow Checker. Wenn der dann da ist, bleibt die Frage: „Warum brauche ich dann überhaupt noch Garbage Collection?“ Am Ende nutzt man Garbage Collection oft nur, weil man sich nicht mit den Objekt-Lifetimes befassen will. Rust zwingt einen, genau diese grundlegenden Fragen selbst zu durchdenken.

  • Rusts Designentscheidungen sind oft schwer nachvollziehbar. Mojo hat ebenfalls einen Borrow Checker, ist aber aus einigen Gründen viel leichter zu lernen als Rust. Erstens gibt es Wertsemantik. In Rust wird Einsteigern oft gesagt, sie sollten einfach überall clone() benutzen, während in typischen statischen Sprachen wie C, C++ oder Go Wertsemantik ohnehin der Standard ist. Zweitens dienen Lifetimes in Mojo nicht dazu festzulegen, ob ein Wert je nach Scope noch benutzt werden darf, sondern wann er gelöscht wird. Wenn noch Referenzen existieren, wird die Lifetime verlängert, und sobald die Nutzung endet, wird sofort gelöscht. Deshalb bekommt man in Mojo keine Fehler wie „der Wert lebt nicht lange genug“. Allein diese beiden Designentscheidungen nehmen schon viel Last heraus.

  • Für Anfänger ist jede Sprache schwer zu lernen, insofern ist Rust da nichts Besonderes. Programmieren hat nun einmal eine Lernkurve.

  • Dass es solche Texte gibt, sagt meiner Meinung nach mehr über den Autor als über die Sprache. Das ist keine Kritik am Autor — ich finde es gut, wenn jemand seine Begeisterung so teilt.

  • Dieser Text spricht eher über die Lernkurve als darüber, welche Probleme Rust eigentlich löst. Für eine sinnvolle Entscheidung, ob sich der Einstieg lohnt, müsste man beides ausgewogen erklären.

  • Über Rusts Design kann man endlos streiten, aber allein aus der Tatsache, dass solche Texte nötig sind, lässt sich die Sprache selbst kaum bewerten. Eher würde ich sagen, Python bräuchte solche Texte noch dringender. Weil immer mehr Programmierer keinen klassischen Engineering-Hintergrund haben, ist Python paradoxerweise eine Sprache, die jeder benutzen kann, während Rust eben nicht für jeden ist. Für manche ist Rust im Vergleich zu C oder Zig sogar deutlich leichter zu lernen. Ich liebe Python auch, halte es im Kern aber für eine schreckliche Sprache. Selbst im LLM-Zeitalter wissen die Leute oft nicht, dass man optimiertes Python schreiben sollte. Auch unsere KI-Freunde erzeugen sonst weiter nur ineffizientes Python, wenn man ihnen nicht ausdrücklich etwas anderes sagt.

  • Auf die Frage „Ist das nicht ein Problem im Sprachdesign?“ wäre meine Gegenfrage schlicht: „Warum?“

  • Aus Sicht von jemandem, der Rust gelernt hat: Selbst wenn man hauptsächlich Python nutzt, habe ich Rust nie als sprachlich mangelhaft empfunden. Im Gegenteil, Rust ist extrem strikt, und je mehr man versucht, es un-rustig zu machen, desto mehr leidet man. Folgt man dagegen dem Rust-Stil, hilft die Sprache umso mehr, je komplexer es wird. In anderen Sprachen entdeckt man Fehler nach und nach zur Laufzeit, in Rust wird fast alles schon beim Kompilieren abgefangen. Logikfehler verhindert Rust natürlich nicht, aber mit der starken Test-Integration kann man gut damit umgehen. Rust hat Nachteile, aber es lohnt sich auf jeden Fall, es wenigstens einmal zu lernen. Die Art, wie Rust Fehler reduziert, lässt sich auch als gute Entwicklungspraxis in anderen Sprachen nutzen.

  • Rust ist tatsächlich so komplex, dass es für LLMs schwer ist, auf Anhieb korrekten Rust-Code zu erzeugen. Trotzdem ist mir das deutlich lieber als viele Probleme von JavaScript oder anderen schwach typisierten bzw. dynamischen Sprachen.

  • Ich habe Rust gelernt und kann deiner Einschätzung zustimmen. Rust ist wirklich komplex und eine typische „committee-designed“-Sprache. Das Tooling ist großartig, und trotzdem ist es zwar weniger komplex als C++, aber ganz sicher keine leicht zu lernende Sprache.

  • Das Problem solcher Texte ist, dass sie den Kern nicht treffen. Es gibt Programme, deren Schreiben Rust grundsätzlich gar nicht erlaubt. Dafür gibt es gute Gründe, aber es ist etwas, das sich grundlegend von fast allen Sprachen unterscheidet, die die meisten Leute bisher benutzt haben. Es gibt definitiv Programme, die man in Rust nicht schreiben kann. Damit muss man leben — sonst ist Rust nichts für einen.

• Ein eher unüblicher Ansatz beim Lernen von Rust ist, zuerst nur einen Teil der Sprache zu lernen. In meinem Rust-Einführungskurs werden Lifetimes zum Beispiel überhaupt nicht gelehrt. Man kann mit Funktionen ohne Lifetimes bereits genügend funktionierende Programme schreiben. Bei Makros gilt dasselbe: Sie sind nicht einfach, aber man sollte trotzdem erst einmal ein Subset lernen. Und statt sich von Anfang an nur auf copy() oder clone() zu verlassen, ist es meiner Meinung nach der bessere Ansatz, zuerst Borrowing zu lernen. Das ist der Kern der Sprache.

• Die einzige Art, Rust wirklich zu lernen, wäre für mich eine große Zahl von Jobs mit mehr als 300.000 Dollar Gehalt. Ich glaube auch, dass Rust Potenzial hat, im Quant-Bereich C++ zu ersetzen. Aber es gibt schon OCaml, und wenn ich eine extrem schwierige und komplexe Sprache lernen soll, möchte ich zuerst Geld sehen. Bisher waren die bestbezahlten Jobs für mich immer Python-Jobs.

• Beim Lesen dieser Kommentare ist mir eine Haltung aufgefallen, die man oft bei älteren Programmierern sieht, wenn sie kritisiert werden. Je länger man arbeitet, desto sturer kann man werden. Jeder sollte sich einmal selbst fragen, warum er Vorschläge des Compilers ablehnt, was er eigentlich anders machen will und was ihn genau daran hindert.