Seite 2: Community, Sprachvergleich und Zukunft

Inhaltsverzeichnis

heise Developer: Wie groß ist die Community, die die Entwicklung der Rust-Sprache unterstützt und eigene Projekte damit umsetzt?

Hoare: Mozilla beschäftigt ein Team von etwa sechs Leuten, die Vollzeit an Rust arbeiten, plus oder minus verschiedene Besucher, Praktikanten, Helfer aus anderen Teilen des Unternehmens und so weiter. Aber die Community an Rust-Entwicklern ist so sehr gewachsen, dass Leute außerhalb von Mozilla genauso viel oder mehr Arbeiten an der Sprache verrichten wie innerhalb. Wir versuchen sehr offen gegenüber Neuankömmlingen und der Mitarbeit anderer zu sein: Die Entwicklung ist auf GitHub transparent, und jeder ist dazu eingeladen mitzuhelfen. Für das derzeit aktuelle Release (0.7) gab es etwa 100 Mitwirkende, und an dem meisten Tagen sind etwa 250 Leute in unserem IRC-Channel.

heise Developer: Ist ein Port von Firefox zu Rust geplant?

Hoare: Wie ich schon gesagt habe, ist Servo die Zielanwendung für die Rust-Entwicklung. Es ist eine Browser-Engine, also kein vollwertiges Browser-Produkt, aber sie könnte in der Zukunft eventuell in einem Browser genutzt werden. Wir sind nicht sicher, welche Produkte, wenn überhaupt, letztlich auf Servo laufen werden. Zu diesem Zeitpunkt ist es ein Experiment, eine Wette auf die Zukunft.

heise Developer: Wie unterscheidet sich Rust vom ähnlich aussehenden Go oder Sprachen wie Erlang, Scala oder Clojure?

Hoare: Das sind alles großartige Sprachen, und ich bin wahrlich kein Freund eines "Kriegs der Sprachen". Verschiedene Sprachen passen zu verschiedenen Communities und Nischen, und was das angeht, bin ich grundsätzlich ein Pluralist. Wir haben bei weitem mehr gemeinsam mit anderen Sprachen (die auf deiner Liste eingeschlossen), als es Unterschiede gibt, und Gemeinsamkeit ist oft die ehrlichste Form der Verehrung: Wir kopieren die Funktionen, die wir mögen!

Abgesehen davon fragt jeder diese Fragen, deshalb liefere ich mal ein paar Unterschiede: Im Vergleich zu Go ist der Hauptunterschied Speichersicherheit und die damit verbundene kognitive Last, sie zu erreichen. Go geht mehr in Richtung Anwenderfreundlichkeit als in Richtung Sicherheit, und so sitzt man am Ende mit Code da, der einfach zu schreiben und zum Laufen zu bringen ist, bei dem es aber Data Races, Nullzeiger, Veränderlichkeitsfehler und Ähnliches gibt.

Im Vergleich zu Erlang hat Rust einen statisch typisierten "Ahead of time"-Compiler. Rust kompiliert mehr wie C oder C++, mit Typenüberprüfung im gesamten Programm und optimiertem Maschinencode als Ausgabe. Das Speicher- und Aufgabenüberwachungsmodell ist dem von Erlang sehr ähnlich, da es unveränderliche Daten bevorzugt, keine Nullzeiger hat, die Eigentumsrechte zwischen Tasks isoliert und es beim Ausfall eine einfache Crash-Restart-Philosophie (Stichwort "Let it Crash", Red.) verfolgt.

Der Hauptunterschied zu Scala ist die JVM, ähnlich wie der VM-Unterschied bei Erlang. Die Werkzeuge und die Laufzeit sind alle unterschiedlich. Scala (und zu einem gewissen Anteil auch Clojure) erbt einige Dinge durch die Ausrichtung auf die JVM, die wir nicht haben wollen, einschließlich der Schwierigkeiten beim Einsatz der langsameren Schnittstelle zu C, den Overhead der allgegenwärtigen Garbage Collection und der GC- sowie zeigerlastigen Objektrepräsentationen. Zusätzlich ist Scalas Nebenläufigkeit anfällig für Data Races, ähnlich wie die von Go.

Clojure scheint Nebenläufigkeit wenigstens direkt angegangen zu haben. Vergleicht man Rust mit Clojure, ist der Hauptunterschied wahrscheinlich (über die mit Scala erwähnten Einschränkungen durch die JVM hinaus), dass Rust überhaupt nicht Lisp ist. Lisp-Sprachen scheinen ausgesprochene "Usability Splits" zu verursachen: Einige Leute mögen sie, einige hassen sie. Ich bin ein alter Lisp-Fan und verstehe nicht, was das Problem der Hasser ist. Allerdings hatten wir das Gefühl, dass wir es uns nicht leisten konnten, eine derartige Menge an Nutzern zu verstimmen, die wir verloren hätten, wenn wir uns für eine Lisp-artige Syntax entschieden hätten. Selbiges gilt für beispielsweise die Forth- oder Haskell-Syntax. Schöne Sprachen, aber wir waren der Meinung, dass wir, um das C++-Publikum anzusprechen, etwas brauchten, dass etwas vertrauter aussieht. Wir haben ein sehr schönes Makrosystem im Lisp-Stil ausgewählt – oder wenigstens das beste, was sich mit C-artiger Syntax umsetzen lässt.

heise Developer: Kannst du die Roadmap zur Version 1.0 beschreiben?

Hoare: Unser Bug Tracker hat Bugs auf Grundlage von Reifegraden des Projekts bestimmten Meilensteinen zugeordnet: ob sie klar definiert sind, rückwärtkompatibel, Feature-complete, ausreichend getestet, produktionsbereit. Wir stufen die Bugs in diese Meilensteine ein und hoffen, dass 1.0-Release so zu behandeln, wie es die Nummer andeutet: Als ein Versprechen von wenigstens Rückwärtskompatibilität, vielleicht ein klein wenig mehr als nur das. Wir hoffen so eine Veröffentlichung irgendwann spät in diesem oder früh im nächsten Jahr zu haben, allerdings lässt sich der Zeitpunkt nur schwer zuverlässig voraussagen. Wir veröffentlichen in jedem Quartal, egal auf welchem Reifegrad wir sind: Unser System zur Integration von Änderungen stellt sicher, dass die Produktqualität nicht zurückgeht.

Zu diesem Zeitpunkt befinden wir uns immer noch in der 0.x-Serie der Entwicklung: auf dem Alpha-Level. Rust ist nicht stabil, und Leute die mit dem momentanen Code arbeiten, sollten mit einigen Brüchen rechnen. Wir werden weiterhin 0.x-Releases herausbringen, bis das Produkt den Reifegrad einer Version 1.0 erreicht hat. Abgesehen davon sind wir bei der siebten Veröffentlichungen im Alpha-Zyklus, und die Zahl der Änderungen, die Brüche verursachen, ist dramatisch zurückgegangen. Im Moment versuchen wir hauptsächlich Sachen anzugehen, von denen wir wissen, dass sie falsch, ineffizient oder zu überraschend für die Nutzer sind. Die Hauptarbeit an den Funktionen ist beendet.

heise Developer: Graydon, wir bedanken uns für die Beantwortung der Fragen.

Frank Müller
arbeitet als Software Engineer bei Canonical. (jul)