Rust lernen durch zehn Projekte – von CLI-Tools bis zu Inferenzdiensten

Viele Entwickler, die mit Rust beginnen, verbringen Wochen damit, sich mit der Syntax und Tutorials auseinanderzusetzen, stocken jedoch beim ersten Versuch, etwas Reales zu bauen. Die Kenntnis der Schlüsselwörter ist nicht dasselbe wie das Verständnis dafür, warum der Borrow Checker Ihr Design ablehnt, wie asynchrone Aufgaben Zustände teilen oder was passieren sollte, wenn ein Socket mitten in einer Anfrage geschlossen wird. Der zuverlässige Weg, diese Lücke zu überbrücken, besteht darin, Projekte zu entwickeln, die solche Fragen unvermeidlich machen. Diese Anleitung stellt zehn solcher Projekte in steigender Schwierigkeitsreihenfolge vor, erklärt, was jedes von ihnen zum Lernen zwingt, und fügt Gewohnheiten hinzu (Iteration, Testing, Benchmarking sowie disziplinierte Nutzung von KI), die ein fertiges Projekt in echte Fähigkeiten verwandeln.

Warum Projekte besser sind als das Auswendiglernen der Syntax

Rust kommt in Systemsoftware, Cloud-Infrastrukturen, Entwicklerwerkzeugen, Sicherheitsprodukten, Blockchain-Plattformen sowie in Teilen der KI-Infrastruktur zum Einsatz. Diese Breite macht es attraktiv, ihn zu erlernen, führt aber auch dazu, dass man ihn nur oberflächlich kennenlernt. Man kann sich alle diese Schlüsselbegriffe merken:

let
mut
fn
struct
enum
trait
impl

und trotzdem feststecken, wenn ein echtes Programm einen gemeinsamen, veränderbaren Zustand zwischen Threads benötigt. Die nützlichsten Lernprojekte sind nicht unbedingt groß – es sind vielmehr jene, die einem vermitteln, warum die Sprache so konzipiert ist, denn sie bringen einen in Situationen, in denen ein naiver Ansatz weder kompiliert noch mit echten Eingaben umgehen kann.

1. Ein Kommandozeilenwerkzeug, das ein reales Problem löst

Fangen Sie klein an und wählen Sie etwas, das Sie tatsächlich verwenden würden. Gute Kandidaten sind ein Protokalanalysewerkzeug, eine Dateisuchfunktion, ein JSON-Formatierer, ein CSV-Verarbeiter, ein Passwortgenerator, ein Verzeichnisscanner oder ein Markdown-Konverter.

Ein Verzeichnisscanner kann beispielsweise wie folgt aufgerufen werden:

$ logscan app.log --level error

und ein Zusammenfassung sowie die entsprechenden Zeilen ausgeben (die erste Ergebniszeile wird hier zusammen mit dem Zusammenfassung ausgeführt):

Found 42 errors12:31:04 Database connection failed
12:31:09 Request timeout
12:31:15 Authentication service unavailable

Selbst ein so kleines Tool berührt erstaunlich viele Aspekte der Sprache:

• Auswertung von Befehlszeilenargumenten
• Lesevorgänge von Dateien und Handhabung von E/A-Fehlern
• Arbeit mit String im Vergleich zu &str
• Modellierung von Daten mit Strukturen und Enumerationen
• Übertragung von Fehlern mithilfe von Result und ?
• Organisierung des Codes in Module
• Schreiben von Unit-Tests

Ebenso wichtig ist, dass es klein genug ist, um fertiggestellt zu werden. Etwas Vollständiges zu versenden, ist eine Fähigkeit für sich, und ein fertiges kleines Werkzeug lehrt mehr als ein aufgegebenes, ehrgeiziges.

2. Ein minimaler HTTP-Server ohne Framework

Bevor Sie zu einem Web-Framework greifen, schreiben Sie einen simplen HTTP-Server auf Basis von TCP. Der zu implementierende Anfragenpfad sieht in etwa so aus:

Client
  ↓
TCP connection
  ↓
HTTP parser
  ↓
Router
  ↓
Handler
  ↓
Response

Dabei lernen Sie TCP und Sockets, die Struktur von HTTP-Nachrichten, das Parsen von Anfragen, das Erstellen von Antworten, die Verwaltung von Puffern, das Eigentum an den zwischen den Schritten fließenden Daten sowie die Verarbeitung mehrerer Verbindungen gleichzeitig. Der Server muss nicht für die Produktion bereit sein; das Verständnis ist das Ziel. Sobald Sie dies von Hand umgesetzt haben, wirken Frameworks wie Axum oder Actix Web nicht mehr wie Magie, denn Sie wissen genau, welche Aufgaben sie Ihnen abnehmen.

3. Eine REST API mit Unterstützung einer echten Datenbank

Danach nähern wir uns einem echten Backend an. Eine API zur Aufgabenverwaltung eignet sich gut dafür, mit den üblichen Ressourcenrouten:

POST   /tasks
GET    /tasks
GET    /tasks/:id
PUT    /tasks/:id
DELETE /tasks/:id

Daraufhin werden PostgreSQL, Authentifizierung, Validierung, strukturierte Fehlerantworten, Logging, Konfigurationsverwaltung sowie Integrationstests hinzugefügt. Hier beginnen die einzelnen Sprachmerkmale, sich zu einer Architektur zusammenzufügen, und es tauchen die wertvolleren Fragen auf: Welcher Layer soll eine bestimmte Logik übernehmen, was die API tun sollte, wenn die Datenbank nicht verfügbar ist, welche Statuscodes und Inhalte ein Client erhalten sollte, wie Fehler vom Speicheralayer zur HTTP-Antwort übertragen werden sollen und wie sich die Konfiguration zwischen den Umgebungen unterscheiden sollte. Solche Designfragen sind weitaus wichtiger als irgendeine einzelne Syntaxregel.

4. Ein konkurrierender Webcrawler

Nun erhöhen wir die Schwierigkeit. Ein Crawler, der viele Seiten auf einmal abruft, breitet sich von einem Ausgangspunkt wie folgt aus:

┌── URL 1
             │
Start ───────┼── URL 2
             │
             ├── URL 3
             │
             └── URL 4

Fügen Sie eine explizite Obergrenze für die Parallelität hinzu:

Maximum concurrent requests: 10

Diese einzige Einschränkung zwingt Sie dazu, Konkurrenzverhältnisse zu verstehen, anstatt einfach Aufgaben zu erstellen und auf das Beste zu hoffen. Sie werden mit asynchronen Funktionen und Aufgaben, Kanälen, gemeinsam genutztem Zustand sowie der damit verbundenen Synchronisierung, Zeitlimits, Wiederholungsversuchen und Bandbreitenbeschränkungen arbeiten. Zudem werden Sie auf Probleme stoßen, die in sequenziellen Programmen nie auftauchen, wie zum Beispiel das Zweiemale-Aufrufen derselben URL von zwei Aufgaben oder ein langsamer Host, der die anderen ausbremst. Genau diese Probleme machen das Projekt zu einem lohnenswerten Bauvorhaben.

5. Ein Schlüssel-Wert-Speicher

Eine kleine Datenbank gehört zu den lohnendsten Lernprojekten. Beginnen Sie mit drei Befehlen:

SET name Rothy
GET name
DELETE name

Dann entwickeln Sie es weiter mit Persistenz auf Disk, Indexierung, Serialisierung, Ablaufzeit von Schlüsseln, Transaktionen sowie sicherm gleichzeitigen Zugriff. Sie versuchen nicht, Redis zu konkurrieren; vielmehr möchten Sie verstehen, wie Speichermotoren funktionieren. Das Projekt trainiert Kenntnisse in Datenstrukturen, Datei-Eingabe/Ausgabe, Speicheraufbau, Serialisierungsformaten, Konkurrenzverhalten, Zuverlässigkeitsgarantien und Leistung. Hier wird auch das Eigentumsmodell von Rust zunehmend sinnvoll statt störend, da Sie nun einen lang lebenden Zustand verwalten, den mehrere Teile des Programms ändern möchten.

6. Ein Miniatur-Redis-Server

Falls Sie an einem Schlüssel-Wert-Speicher interessiert sind, wandeln Sie ihn in einen kleinen Netzwerkserver um, der ein redis-ähnliches Protokoll verwendet:

SET user:1 Rothy
GET user:1
DEL user:1

und unterstützen Sie die Ablaufzeit basierend auf Zeit:

EXPIRE user:1 60

Im Laufe der Zeit können Sie TCP-Verbindungen von mehreren Clients hinzufügen, Befehle parsen, gleichzeitige Anfragen verarbeiten, in-Memory-Speicher nutzen, Daten dauerhaft speichern, Ablaufzeiten steuern sowie Benchmarks durchführen. Das Projekt vereint Netzwerktechnologien, Datenstrukturen, Konkurrenzverarbeitung und Systemdesign und zwingt Sie dazu, über Abwägungen nachzudenken. Soll der Server sich auf Latenz, Durchsatz, Speicherverbrauch oder Langlebigkeit optimieren? Es gibt selten eine einzige richtige Antwort, und zu lernen, bewusst zu wählen sowie die Wahl zu begründen, ist eine der am meisten übertragbaren Lektionen auf dieser Liste.

7. Eine Auftragswarteschlange mit Arbeitern

Eine Auftragswarteschlange ist eine hervorragende Übung für Backend-Systeme. Der grundlegende Ablauf ist:

Producer
   ↓
Job Queue
   ↓
Workers
   ↓
Results

mit Aufträgen, die Arbeitseinheiten wie folgt darstellen:

send_email
generate_report
process_image
run_test

Beginnen Sie mit Arbeitern, die wiederholt die nächste Aufgabe abrufen und ausführen. Fügen Sie anschließend mehrere Arbeiter, Wiederholungsversuche, Statusverfolgung der Aufgaben, Zeitlimits, Fehlerbehandlung sowie einen ordnungsgemäßen Abstopp hinzu, bis das Design wie folgt aussieht:

Producer
    ↓
┌───────────────┐
│   Job Queue   │
└───────────────┘
   ↓    ↓    ↓
Worker Worker Worker

Die zentrale Lektion ist, dass Software nicht nur um den erfolgreichen Ablauf geht. Eine Aufgabenschlange ermöglicht es Ihnen, zu entscheiden, was passiert, wenn eine Aufgabe auf halbem Weg fehlschlägt, ein Arbeiter abstürzt oder der Prozess während laufender Arbeit gestoppt werden soll. Das Planen für solche Szenarien ist es, was eine Demo von einem echten System unterscheidet.

8. Ein Log-Aggregator

Für etwas, das der Produktionsentwicklung näher kommt, bauen Sie einen kleinen Dienst zur Sammlung von Logs. Mehrere Anwendungen senden ihre Logs an einen Sammler, der sie speichert:

Application A ──┐
Application B ──┼──> Log Collector ──> Storage
Application C ──┘

Der Sammler kann Logs über HTTP oder rohes TCP empfangen und eine Abfrageschnittstelle bereitstellen:

GET /logs?level=error
GET /logs?service=payment
GET /logs?from=...

Die Arbeit umfasst Netzwerke, Serialisierung, parallele Eingabeverarbeitung, Filtern, Umgang mit Zeitstempeln, Speicherlayout, Leistung und Überwachbarkeit. Es ist außerdem ein idealer Ort, um zu lernen, wie sich ein Service unter Last verhält: Was passiert, wenn die Eingabe schneller erfolgt als der Speicher ausreicht, wie viel Speicherpufferung kostet und wie sich die Abfragegeschwindigkeit mit wachsenden Datenmengen verändert.

9. Eine kleine Unix-Shell

Dieses Projekt ist unangenehm in der Handhabung – und genau das macht es nützlich. Beginnen Sie mit dem Ausführen einfacher Befehle:

$ echo hello
hello

und dem Umgang mit eingebauten Befehlen neben externen Programmen (der Prompt des zweiten Befehls wurde hier mit dem Ausgabeergebnis des ersten zusammengeführt):

$ pwd
/home/user$ ls
file1.txt
file2.txt

Fügen Sie anschließend die Ausführung von Befehlen, Umgebungsvariablen, Pipes, Umleitung, Hintergrundprozesse und Signalverarbeitung hinzu, bis schließlich Pipelines wie folgt entstehen:

cat access.log | grep ERROR | sort

Zu diesem Zeitpunkt programmieren Sie direkt am Betriebssystem. Sie lernen, wie Prozesse erstellt und verwaltet werden, wie stdin, stdout und stderr miteinander verbunden sind, wie Umgebungsvariablen vererbt werden, wie Pipes Prozesse miteinander verbinden und welche OS-APIs dahinterstecken. Nur wenige Projekte helfen dabei, aufzuklären, was tatsächlich passiert, wenn man in einer Terminalkonsole die Eingabetaste drückt.

10. Ein kleiner AI-Inferenzdienst

Das abschließende Projekt spiegelt den Stand der Entwicklung neuer Infrastruktur wider. Das Ziel besteht nicht darin, ein Modell zu trainieren, sondern einen Dienst darauf aufzubauen:

Client
  ↓
Rust API
  ↓
Request Queue
  ↓
Inference Worker
  ↓
Model
  ↓
Response

Ein nützliches Service-Tool nimmt Inferenzanfragen entgegen, validiert die Eingaben, stellt Aufgaben in eine Warteschlange, verarbeitet Anfragen gleichzeitig, gibt Ergebnisse zurück, protokolliert die Latenzzeit, setzt Zeitlimits durch und stellt Metriken bereit. Die interessanten ingenieurtechnischen Aspekte liegen in der Infrastruktur und nicht im Modell selbst. Man kann mit Grenzen für die Parallelisierung, Gruppierung von Anfragen, Caching, Zulassungskontrolle, Speichernutzung, Latenzbudgets, Wiederholungsversuchen sowie Überwachungsmöglichkeiten experimentieren. Genau hier wird Rusts Kontrolle über Speicher und Parallelisierung direkt relevant für die Systeme hinter KI-Anwendungen.

Konzentrieren Sie sich auf ein Projekt statt auf zehn

Es ist nicht notwendig, hier jedes Projekt zu entwickeln – das ist in der Regel ein Fehler. Wählen Sie eines aus, fertigen Sie es ab und verbessern Sie es anschließend weiter. Ein erster Meilenstein könnte sein:

Version 1
Basic functionality

danach folgen nacheinanderere Versionen, die jeweils eine neue Funktion hinzufügen (die Pfeile und Versionsbezeichnungen sind in dieser Auflistung zusammen angezeigt):

        ↓Version 2
Better error handling        ↓Version 3
Tests        ↓Version 4
Concurrency        ↓Version 5
Persistence        ↓Version 6
Benchmarking        ↓Version 7
Production-style monitoring

Der größte Lerneffekt entsteht in diesem Verbesserungslauf. Jede Version zwingt einen dazu, frühere Entscheidungen erneut zu überdenken, und das Refaktorieren des eigenen Codes unter neuen Anforderungen bringt weitaus mehr beim Lernen ein als das Starten eines neuen Projekts von Grund auf.

Die Fragen, die diese Projekte zum Stellen trainieren

Das Erlernen von Rust ist eigentlich nicht das Ziel; vielmehr geht es darum, zu lernen, wie man über Software nachdenkt. Die oben genannten Projekte stellen einem ständig dieselben Fragekategorien:

• Speicher: Wer besitzt diese Daten, und wie lange existieren sie?
• Konkurrenz: Was passiert, wenn zwei Aufgaben gleichzeitig darauf zugreifen?
• Fehler: Was sollte geschehen, wenn diese Operation fehlschlägt?
• Netzwerk: Was passiert, wenn der Client mitten im Vorgang abbricht?

Leistung: Wo liegt das eigentliche Engpassproblem?

Sicherheit: Welche Eingaben kann der Benutzer steuern?

Toverlässigkeit: Was passiert, wenn eine Abhängigkeit nicht verfügbar ist?

Diese Fragen gelten für jede Sprache. Rust zwingt einen einfach dazu, vielen davon bereits früher gegenüberzutreten – oft schon zur Kompilierzeit – anstatt erst in der Produktion.

Eine vorgeschlagene Vorgehensweise

Falls Sie von vorne anfangen, klettern Sie die Leiter empor, anstatt direkt auf die schwierigste Stufe zu springen:

• Anfänger: Das CLI-Tool, zur Einführung in die Sprache und zum Umgang mit Fehlern.
• Anfänger bis Mittelstufe: Der HTTP-Server, für Netzwerkkonzepte und grundlegende Mechanismen.
• Mittelstufe: Die REST-API, für eine echte Backend-Architektur.
• Mittelstufe: Der parallele Crawler, für asynchrone Codestrukturen und Konkurrenz.
• Mittelstufe bis Fortgeschrittenenstufe: Der Schlüssel-Wert-Speicher, für Speicherung und Zustandsverwaltung.
• Fortgeschritten: Der Redis-Klon, der Netzwerkfunktionen, Konkurrenzverarbeitung und Speicherung kombiniert.
• Fortgeschritten: Die Auftragswarteschlange, für ein Denken im Rahmen verteilter Systeme.
• Fortgeschritten: Der Protokollaggregator, für Überwachbarkeit und praktische Anwendungsszenarien in der Produktion.
• Fortgeschritten: Die Shell, für Konzepte des Betriebssystems.
• Zukunftsorientiert: Der Inferenzdienst, der Rust mit moderner KI-Infrastruktur verbindet.

Testen ab dem ersten Tag

Lassen Sie das Testen nicht bis zum Schluss warten. Für jedes Projekt sollten normales Verhalten, ungültige Eingaben, leere Eingaben, Grenzkonditionen, gleichzeitige Operationen, Fehlerwege, Zeitüberschreitungen und Wiederherstellungsmechanismen abgedeckt werden. Wenn ein Endpunkt eine Benutzer-ID erfordert, reicht ein einziger Test für einen erfolgreichen Ablauf wie dieser nicht aus:

GET /users/123

Testen Sie daher auch Nullwerte, negative Zahlen, nicht numerische Werte, sehr große IDs sowie fehlende Segmente:

GET /users/0
GET /users/-1
GET /users/abc
GET /users/999999999
GET /users/

Hier verschmelzen Programmierung und Testing zu einer Disziplin. Ein Programm, das nur dann funktioniert, wenn alles reibungslos verläuft, ist noch nicht fertiggestellt. Rusts eingebautes cargo test macht es einfach, solche Fälle zusammen mit dem Code zu verwalten.

Benchmark statt Annahmen

Rust hat den Ruf, schnell zu sein – messen Sie daher lieber als anzunehmen. Ein Lasttest an Ihrem Server kann einen Bericht wie folgt liefern; die Zahlen dienen nur zur Veranschaulichung, und Ihre Ergebnisse hängen vollständig von Hardware und Arbeitslast ab:

Requests:       100,000
Average:        4.2 ms
P95:            7.1 ms
P99:            11.4 ms
Throughput:     23,800 req/s

Erstellen Sie eine Baseline, ändern Sie etwas und messen Sie erneut. Achten Sie auf späte Verzögerungen wie P95 und P99, nicht nur auf den Durchschnitt – denn genau dort treten in der Regel Konflikte und Zuweisungsprobleme auf. Das Messen vor und nach ist die Gewohnheit, die die Optimierung auf Fakten statt auf Annahmen stützt.

Nutzen Sie KI-Assistenten, ohne das Lernen zu vernachlässigen

KI-basierte Programmierwerkzeuge können heute viel Code in Rust für Sie erstellen: Strukturen, API-Handler, Tests, Datenbankabfragen, Fehlerarten und Dokumentation. Das ist tatsächlich nützlich, doch wenn das Ziel des Projekts darin besteht, als Programmierer zu verbessern, führt das Überlassen des gesamten Denkprozesses dem Zweck zuwider. Ein besseres Vorgehen besteht darin, die Lösung selbst zu entwerfen und umzusetzen, bevor man einen Assistenten bittet, sie zu überprüfen – beispielsweise nach Problemen bei der Eigentumsverwaltung, Konkurrenzfehlern, Lücken in der Fehlerbehandlung oder unnötigen Speicherzuweisungen. Eine solche Überprüfung bringt einem etwas bei; die Bitte um eine Überprüfung der gesamten Anwendung nicht. Es geht nicht darum, KI zu vermeiden, sondern sie ohne Aufgabe des Lernens einzusetzen.

Was der vollständige Satz umfasst

Durch die ordnungsgemäße Durchführung von bereits drei oder vier dieser Projekte werden Sie mit einem breiten Spektrum des Softwareengineering konfrontiert:

Rust
 │
 ├── Ownership
 ├── Borrowing
 ├── Error handling
 ├── Traits
 ├── Generics
 │
 ├── Networking
 ├── Concurrency
 ├── Async programming
 │
 ├── Databases
 ├── APIs
 ├── Operating systems
 │
 ├── Testing
 ├── Benchmarking
 ├── Observability
 │
 └── System design

Diese Breite ist weitaus wertvoller als ein weiterer abgeschlossener Tutorial.

Hauptergebnisse

• Wählen Sie Projekte, die Sie dazu zwingen, sich mit Verantwortung, Konkurrenz und Fehlern auseinanderzusetzen – nicht nur mit Syntax.
• Fangen Sie mit etwas Kleinem an, das Sie abschließen können, und arbeiten Sie sich anschließend zu Themen wie Netzwerken, Speicherung und Betriebssystemebene vor.
• Iterieren Sie an einem Projekt über mehrere Versionen, anstatt viele Projekte gleichzeitig zu starten.
• Testen Sie von Anfang an Randfälle und Fehlerwege sowie alle behaupteten Verbesserungen.
• Lassen Sie KI Ihr Design und Ihren Code überprüfen, aber entwerfen Sie selbst.
• Das beste nächste Projekt ist das, das Ihnen hilft, etwas zu verstehen, was Sie derzeit noch nicht wissen: Fangen Sie klein an, brechen Sie es auf, testen Sie es, analysieren Sie seine Leistung, beheben Sie Fehler und machen Sie es anschließend schwieriger.