Seite 3: Einstieg, Stabilität, Zukunft

Inhaltsverzeichnis

Abgesicherter Einstieg

Das Rust-Projekt sieht Dokumentation als "First-Class Citizen" an. Steve Klabnik, unter anderem bekannt durch seine Arbeit an Rails und seinen Blog-Artikeln auf "Rust for Rubyists", wurde von Mozilla als Dokumentationsautor für Rust angestellt. Spätestens seit seinem Engagement wird die Dokumentation von Sprache und Standardbibliothek liebevoll gepflegt und pünktlich aktualisiert. Er ist außerdem Autor des Online-Buchs "The Rust Programming Language", das mit ausführlichen Erklärungen und Beispielen den Einstieg erleichtern soll.

Rust-Code kann spezielle rustdoc-Kommentare im Markdown-Format enthalten, die, ähnlich wie Javadoc, die Nutzung und Funktionsweise von Bibliotheken beschreiben. Aus diesen Kommentaren lässt sich mit dem Befehl cargo doc auch eine HTML-Seite mit vollständig verlinkter und durchsuchbarer Dokumentation generieren. Selbst die Rust-Standardbibliothek ist vollständig mit rustdoc dokumentiert.

Eine Besonderheit von rustdoc sind die sogenannten Doctests. In eine rustdoc lässt sich nicht nur Markdown, sondern auch Beispiel-Code einfügen. Dieser wird dann durch den Befehl cargo test ausgeführt. Es ist gängige Praxis, rustdoc-Beispiele mit assert-Anweisungen zu versehen, die sicherstellen, dass alles korrekt funktioniert. Das wird unter der Kategorie Doctest in der Ausgabe angezeigt.

/// Multiplies two integers
/// # Examples
/// '''
/// let x = multiply(2,2);
/// assert_eq!(x, 4);
/// '''
fn multiply(x: i32, y: i32) -> i32 {
  x * y
}

Compiler-Diagnostik

"Diagnostiken sind die User Experience eines Compilers und verdienen genau dieselbe Aufmerksamkeit, die einer Mobil-Applikation oder Web-Design gewidmet wird", sagt Patrick Walton, einer der Köpfe hinter Rust. Entsprechend bietet der Rust-Compiler etliche Hilfestellungen. Die Konsolenausgabe ist gut strukturiert und weist nicht nur auf den Fehler, sondern auch auf die mögliche Ursache hin. Deprecations besitzen üblicherweise einen kleinen Hinweis, warum die Änderung gemacht wurde und was stattdessen verwendet werden sollte.

Der Compiler hat eine ganzen Menge nützlicher und gut erklärter Lints an Bord. Zum Beispiel löst ein nicht weiterverwendetes Result eine Warnung aus – es könnte ja ein Fehler aufgetreten sein, der sonst vergessen würde. Dazu lässt sich die Warnung auch pro Bibliothek in einen Fehler verwandeln.

Aber nicht nur vermutliche Fehler sind abgedeckt: Optional ist es auch, Dokumentation verpflichtend zu machen. Zukünftig geplante (und in den Entwicklungsversionen verfügbare) Features sind die Möglichkeit, Plug-ins für den Compiler zu entwickeln, um zum Beispiel auch Autokomplettierung auf Basis des Typsystems anzubieten.

Antrainierte Stabilität

Obwohl viele Rust-Bibliotheken bis vor einigen Monaten stets die neueste Entwicklungsversion des Compilers verlangten, fühlt sich die Sprache dennoch stabil an. Das hat mehrere Gründe: Obwohl sich Rust im letzten Jahr massiv veränderte, wurden damals schon alle signifikanten Änderungen durch einen RFC-Prozess dokumentiert und diskutiert. Auch Deprecations wurden in dieser Zeit ordentlich durchgeführt, häufig mit gut geschriebenen Meldungen, wodurch das Feature ersetzt wurde. Regelmäßig gab es Releases, auch wenn diese nur Training für den Release-Prozess waren. Das rundet eine seit Dezember anhaltende Alpha- und Beta-Phase mit regelmäßigen Releases ab.

Die Stabilität zeigt sich vor allem auch darin, dass inzwischen viele Bibliotheken die Beta-Versionen verwenden – bald wird man alles Wichtige auf 1.0.0 portiert sehen.

Versionierung: der Rolling Compiler

Der Rust-Compiler soll regelmäßig mit neuen Updates und unter Umständen neuen Features versorgt werden. Das wird in dem von Chrome, Firefox und Ember.js praktizierten Release-Modell geschehen:

• Der Master-Branch soll immer kompilieren.
• Alle sechs Wochen wird der Nightly-Build zur Beta-Version.
• Nach weiteren sechs Wochen wird diese Beta-Version zur Release-Version.

Das Ziel ist es, die Community in kleinen Schritten an Änderungen heranzuführen. Der Portieraufwand soll gering gehalten werden, um große Umbauarbeiten zu neuen Versionen zu verhindern. Gleichzeitig geht Rust aber strikte Abwärtskompatibilitätsgarantien ein: Was einmal stabil war und veröffentlicht wurde, wird nicht mehr entfernt. Wie gut sich diese Strategie mit den Release-Prozessen der Linux-Distributionen verträgt, wird die Zukunft zeigen.

Fallstudien

Ein viel genannter Makel des Ökosystems war bisher die Instabilität der Sprache selbst. Viele Features und sogar vollständige Standardbibliotheken wurden nach langen Diskussionen völlig entfernt oder neu geschrieben. Wer früh zur Sprache gekommen war, war es gewohnt, nach jedem Update auf die neueste Sprachversion Programme und Bibliotheken an die Änderungen anzupassen, bevor sie wieder kompilierten.

Die Kompromisslosigkeit des Rust-Teams während der Entwicklungsphase hat in hohem Maße zur Qualität der Sprache beigetragen. Dennoch hielten die häufigen "breaking changes" gerade Unternehmen bisher von der Adaption ab. Es wird sich zeigen, ob das neue Stabilitätsversprechen von Rust 1.0 das Vertrauen von Industrie und Open-Source-Basis vergrößern kann.

Trotz der lange vorherrschenden Instabilität konnten sich einige Rust-Projekte etablieren. Hier zeigt sich, wo der Kern-Anwendungsbereich von Rust in Zukunft liegen könnte: In den Bereichen Browserentwicklung, Spieleentwicklung, Embedded Systems und als Endpunkt einer nativen Schnittstelle mit Skriptsprachen.

Beispiel 1: Servo

Servo ist eine neuartige Browser-Engine, geschrieben in Rust und finanziert von Mozilla, teilweise ist auch Samsung an dem Projekt beteiligt. Sie setzt es sich zum Ziel, jeden technischen Aspekt eines Webbrowsers von Grund auf zu überdenken und zu überarbeiten. Die Kernpunkte sind ein Höchstmaß an Nebenläufigkeit sowie vollständige Eliminierung von Problemen wie Speicherlecks oder Sicherheitslücken, die durch falsche Speicherverwaltung hervorgerufen werden.

Das Team hinter Servo ist der Meinung, dass herkömmliche Browser mit C++-basierter Architektur und eingefahrener Codebasis diese Herausforderungen nicht mehr lösen können. Stattdessen starten sie von vorne und setzen auf Rust, das Speichersicherheit und Parallelismus ohne Data Races garantiert und dabei vergleichbare Geschwindigkeit wie C++ bietet. Das ermöglicht Servo, sich auf die Implementierung einer performanten Browser-Engine zu konzentrieren, ohne Angst vor den meisten Problemen, mit denen die Entwicklungsteams der etablierten Browser wie Firefox oder Chrome seit Jahren kämpfen.

Servo rendert bereits komplexe Webseiten in zufriedenstellender Qualität. Das Projekt nutzt Cargo als einzige Build-Toolchain und stellt alle Bibliotheken einzeln zur Verfügung.

Beispiel 2: Skylight

Skylight ist ein Werkzeug zur Performance-Analyse von Rails-Applikation. Die erste Version wurde in Ruby geschrieben, doch dann stellte Erfinder Yehuda Katz, mittlerweile Mitglied des Rust-Teams, ungewöhnlich hohen Speicherverbrauch der Applikation auf Kundenservern fest. Die Versuche, den Ruby-Code performanter zu gestalten, erzielten nur mäßigen Erfolg.

Katz hatte mit Ruby, einer dynamisch typisierten Sprache mit Garbage Collection, zu wenig Kontrolle über den Systemspeicher und entschied sich zu einem Experiment. Er schrieb die speicherkritischsten Komponenten seiner Applikation in Rust – offenbar mit durchschlagendem Erfolg. Rust wurde fester Bestandteil von Skylight, Katz und Mitgründer Tom Dale zu aktiven Fürsprechern der Sprache.

Rust zeichnet sich für Skylight durch seine Fähigkeit aus, seine eigene Maschinennähe nur bei Bedarf zur Verfügung zu stellen und nahezu immer sicheres und produktives Programmieren performanter Applikationen zu ermöglichen. Katz meint, ohne Rust würde Skylight vielleicht nicht mehr existieren. Es wären Qualitätsstandards "wie bei der NASA" nötig, um C++-Code an die Stabilität von Rust heranzubringen. Besondere Sorge unter C++ bereitete ihm die Möglichkeit von Segmentierfehlern, die die gesamte Kundenapplikation zum Absturz bringen würden.