Stabilität als Ergebnis

Originalautor: Aaron Turon und Niko Matsakis
  • Übersetzung
Dieser Artikel ist eine Übersetzung des zweiten Teils einer Reihe von Blog-Posts, die der bevorstehenden Veröffentlichung der ersten stabilen Version von Rust gewidmet sind. Die Übersetzung des ersten Teils finden Sie hier .

Bitte senden Sie Kommentare zur Übersetzung in PM.




Die bevorstehende Veröffentlichung von Rust 1.0 bringt viele wichtige Dinge mit sich, aber die wichtigste ist unser Bemühen, Stabilität zu gewährleisten, ähnlich wie unser ständiger Fokus auf Sicherheit.

Ab Version 1.0 werden wir mit einem sechswöchigen Release-Zyklus und einer Reihe von „Channels“ fortfahren. Der stabile Release-Kanal wird schmerzlose Updates bereitstellen, und der nächtliche Build-Kanal wird Pionieren den Zugriff auf die Funktionen ermöglichen, an denen derzeit gearbeitet wird.



Das Streben nach Stabilität


Seit seinen Anfängen in Rust sind nur zwei Dinge unverändert geblieben - Sicherheit und Veränderung und manchmal auch nur das zweite. Bei der Entwicklung von Rust stießen wir oft auf Sackgassen, so dass die Freiheit, die Sprache zu ändern, absolut notwendig war.

Aber seitdem ist Rust "gereift", und seine Hauptaspekte haben sich seit geraumer Zeit nicht geändert. Ihre Architektur erscheint uns endlich richtig. Außerdem können Sie jetzt ein echtes Interesse an der Sprache feststellen, das nur im Vorgriff auf die Veröffentlichung der stabilen Version 1.0 verhalten ist.

Es ist sehr wichtig zu klären, was wir unter Stabilität verstehen. Dies bedeutet nicht, dass Rust aufhört, sich zu entwickeln. Wir werden regelmäßig neue Versionen der Sprache veröffentlichen und hoffen, dass die Benutzer die Umgebung für ihre Projekte so oft aktualisieren. Dafür sollte der Update-Vorgang selbst jedoch schmerzlos sein.

Wenn sehr einfach, dann ist es unsere Verantwortung, sicherzustellen, dass Sie keine Angst haben, Rust zu aktualisieren. Wenn Ihr Code mit der stabilen Version 1.0 kompiliert wurde, sollte er auch mit der stabilen Version 1.x mit einem Minimum an Aufwand kompiliert werden.

Unser Plan


Wir werden die Version des "Zug" -Modells verwenden, die zum ersten Mal in der Entwicklung von Webbrowsern verwendet wurde und nun weit verbreitet ist, um Stabilität zu gewährleisten und Stagnation zu verhindern:

  • Neue Funktionen werden direkt zum Hauptzweig hinzugefügt.
  • Jeden Tag wird der letzte erfolgreiche Build, der auf dem Hauptzweig basiert, eine neue nächtliche Veröffentlichung.
  • Alle sechs Wochen wird aus dem aktuellen Stand des Hauptzweigs ein Beta-Zweig erstellt und die vorherige Beta-Version für stabil erklärt.


Mit anderen Worten, wir werden drei Release-Kanäle haben - nächtliche Builds, Beta-Builds und stabile Releases, mit regelmäßiger Beförderung von einem Kanal zum nächsten.

Neue Funktionen und eine neue API werden unter Verwendung von Feature-Gate- bzw. Stabilitätsattributen als instabil gekennzeichnet. Instabile Funktionen und Standard-Bibliotheks-APIs sind nur im nächtlichen Build-Channel verfügbar und nur, wenn Sie ausdrücklich zugestimmt haben, sie zu verwenden.

Beta- und Stable-Versionen enthalten hingegen nur Funktionen und APIs, die als stabil gekennzeichnet sind . Dies bedeutet, dass besonders darauf geachtet wird, den Code, der sie verwendet, nicht zu beschädigen.

Häufig gestellte Fragen


Viele Details sind in den beschriebenen Prozess involviert, und wir werden den RFC veröffentlichen, in dem wir mehr darüber sprechen werden. Der Rest dieses Beitrags konzentriert sich auf die wichtigsten Funktionen und potenziellen Bedenken in Bezug auf unseren Plan.

Welche Funktionen werden in 1.0 stabilisiert?


Wir haben die vorhandene Infrastruktur des Rust-Ökosystems analysiert, um die am häufigsten verwendeten Bibliotheken (Kisten) und Feature-Gates zu identifizieren, und bauen auf diesem Stabilisierungsplan auf. Die gute Nachricht: Der überwiegende Teil der Funktionalität, die derzeit aktiv genutzt wird, wird in Release 1.0 als stabil markiert:

  • Einige Features, die fast fertig sind: Strukturoptionen (Aufzählungen), t und neue Parameter standardmäßig, Indizierung von Tupeln und Syntax zum Erstellen von Slices.
  • Zwei Schlüsselelemente der Sprache, an denen noch gearbeitet werden muss, sind Unboxed Closures und zugehörige Typen.
  • Wichtige Features, bei denen wir vor 1.0 keine Zeit mehr haben, sind mehrere (globale) Importe, Makros und Syntaxerweiterungen. Hier müssen wir schwierige Entscheidungen treffen.


Nach langen Diskussionen haben wir beschlossen, mehrere Importe und Makros in Release 1.0 stabil zu lassen. Wir glauben, dass Probleme mit Glob-Importen gelöst werden können, ohne die Abwärtskompatibilität zu beeinträchtigen. Für Makros bieten wir wahrscheinlich eine zusätzliche Möglichkeit, sie später zu definieren (mit verbesserter Hygiene ), bis die vorhandenen „Makrodefinitionen“ schrittweise verbessert werden. In Release 1.0 wird die gesamte vorhandene Unterstützung für Makros, einschließlich deren Import / Export, stabilisiert.

Auf der anderen Seite können wir nichtDeklarieren Sie Syntaxerweiterungen, die Compiler-Plug-Ins mit vollem Zugriff auf ihre Interna sind, als stabil. Dies bedeutet, dass das gesamte interne Gerät des Compilers für immer repariert wird. Daher müssen wir eine durchdachtere Schnittstelle zwischen den Erweiterungen und dem Compiler entwickeln, und daher bleiben die Syntaxerweiterungen beim Feature-Flag in 1.0.

In vielen wichtigen Fällen können Syntaxerweiterungen durch die herkömmliche Codegenerierung ersetzt werden, und ihre Unterstützung wird bald in Cargo enthalten sein. Wir werden Bibliotheksautoren dabei helfen, von Syntaxerweiterungen zu Release 1.0 abzurücken. Da jedoch eine große Anzahl von Erweiterungen nicht in dieses Modell passt, hat ihre Stabilisierung nach der Veröffentlichung von 1.0 eine hohe Priorität.

Welche Teile der Standardbibliothek werden in 1.0 stabil sein?


Wir stabilisieren die Standardbibliothek nach und nach und haben Pläne für fast alle Module. Es wird erwartet, dass der überwiegende Teil der Funktionalität der Standardbibliothek als stabil bis 1.0 eingestuft wird. Darüber hinaus übertragen wir die experimentellsten Teile der API in separate Bibliotheken (Kisten).

Was ist mit Stabilitätsattributen außerhalb der Standardbibliothek?


Bibliotheksentwickler können weiterhin die Stabilitätsattribute für ihren Code verwenden. Diese Attribute werden nicht mit den Standard-Rust-Release-Kanälen verknüpft. Mit anderen Worten, wenn Sie mit stable Rust kompilieren, können Sie nur die stable API aus der Standardbibliothek verwenden, aber Sie können die experimentellen Elemente anderer Bibliotheken ausprobieren. Rust-Release-Kanäle sind für ein schmerzloses Update von Rust selbst (dem Compiler und der Standardbibliothek) vorgesehen.

Bibliotheksautoren sollen sich an die Spezifikation der semantischen Versionen halten . In Kürze werden wir einen RFC veröffentlichen, der die Beziehung zwischen Stabilitätsattributen und semantischen Versionen definiert.

Warum nicht die Verwendung instabiler Funktionen mit einer stabilen Version zulassen?


Bei der Verwendung instabiler Sprachelemente und Bibliotheken in stabilen Releases treten drei Probleme auf.

Erstens : Wie oft kann in der Web - Entwicklung Feld zu sehen ist, nur ankündigen instabil etwas nicht hilft. Sobald Features zumindest ein wenig verbreitet sind, ist es sehr schwierig, sie zu ändern. und sobald Funktionen im Prinzip verfügbar werden, ist es sehr schwierig, ihre Verwendung zu verhindern. Mechanismen wie Herstellerpräfixe im Web, die ursprünglich für das Experimentieren mit Features entwickelt wurden, sind de facto zum Standard geworden.

Zweitens sind instabile Elemente per Definition unvollständig und werden ständig weiterentwickelt. Beta- und Stable-Versionen „frieren“ sie jedoch zu festgelegten Zeiten ein, während Bibliotheksentwickler mit ihrer neuesten Version arbeiten möchten.

Und schließlich können wir die Stabilität von Rust einfach nicht gewährleisten, wenn wir nicht auf der Umsetzung bestimmter Regeln bestehen. Wir versprechen, dass Sie, wenn Sie eine stabile Version von Rust verwenden, völlig furchtlos für die nächste Version aktualisiert werden können. Wenn Bibliotheken von Drittanbietern von Instabilitäten in Rust abhängen würden, könnten wir dieses Versprechen nur einhalten, wenn die Autoren dieser Bibliotheken dasselbe garantieren würden, indem sie ihre Bibliotheken für alle drei Kanäle gleichzeitig unterstützen.

Es ist völlig unrealistisch und im Prinzip nicht erforderlich, das gesamte Ökosystem dazu zu bringen, diese Probleme zu lösen. Stattdessen stellen wir die Regel auf, dass wenn etwas stabil ist, es tatsächlich stabil ist und ein stabiler Kanal nur stabile Funktionen bietet.

Wird sich das Ökosystem aufteilen? Werden nicht alle auch nach der Veröffentlichung nächtliche Builds verwenden?


Nein, das Ökosystem wird nicht geteilt: Dieser Ansatz hebt nur seine Teilmenge hervor. Entwickler, die mit dem nächtlichen Kanal arbeiten, können frei Bibliotheken verwenden, die für eine stabile Version der Sprache entwickelt wurden. Die wichtigsten Funktionen und APIs werden sich irgendwie stabilisieren, sodass es im Laufe der Zeit immer weniger Gründe geben wird, in einer instabilen Welt zu bleiben.

Wir haben Release 1.0 so geplant, dass der Großteil des vorhandenen Ökosystems in die Kategorie „stable“ fällt, sodass Anfänger, die gerade erst mit Rust anfangen, die große Mehrheit der vorhandenen Bibliotheken in Release 1.0 sofort verwenden können.

Unter welchen Bedingungen ist Stabilität gegeben?


Wir behalten uns das Recht vor, Fehler im Compiler zu beheben, Sicherheitslücken zu schließen und Typ-Inferenz-Algorithmen zu ändern, sodass möglicherweise zusätzliche Typanmerkungen erforderlich sind. Wir sind der Meinung, dass diese Art von Änderung beim Upgrade von Rust keine ernsthaften Kopfschmerzen verursachen sollte.

Die Stabilitätsfunktionen in der API werden in der zukünftigen RFC-Version beschrieben. Im Allgemeinen sind sie jedoch auch so konzipiert, dass Sie ein Upgrade einfacher durchführen können.

Wird sich Rust und sein Ökosystem weiterhin so aktiv entwickeln wie jetzt?


Auf jeden Fall ja! Da ständig neue Änderungen in der Hauptniederlassung vorgenommen werden, verlangsamt das „Zug“ -Modell die Entwicklung nicht und führt nicht zu künstlichen Verzögerungen. Dank unserer großartigen Community hat sich Rust immer sehr schnell weiterentwickelt, und wir sind zuversichtlich, dass sich das Tempo in Zukunft nur noch beschleunigen wird.

Jetzt auch beliebt: