Gedanken zu Rust 2019

Kollegen, guten Abend allerseits!

Wir freuen uns, Ihnen eine Übersetzung eines wirklich programmatischen Artikels von Raf Levin anbieten zu können, dessen titanische Arbeit zur Entwicklung der Rust-Sprache Respekt und Ehrfurcht hervorruft:



Ohne falsche Bescheidenheit und ohne Hass reagierte ein objektiv und enthusiastisch angesehener Autor auf den Appell der Rust-Community, der am Anfang dieses Artikels durch Bezugnahme veröffentlicht wurde. Wir hoffen, dass es interessant und lebensbejahend geworden ist.


Kürzlich schlug das Rust Core Team vor, Artikel mit Meinungen darüber zu schreiben, wie Rust 2019 wachsen soll. Hier ist meine Meinung.

Lebenszyklus der Reifung

In diesem Artikel werde ich den Lebenszyklus der Reifung in einer extrem vereinfachten Form betrachten. Lassen Sie es nur aus drei Phasen bestehen: Forschung, Entwicklung, Polieren. Die verschiedenen Elemente von Rust unterscheiden sich in ihren unterschiedlichen Reifegraden. Dies ist wichtig, wenn Sie versuchen, die aktuelle Phase der Sprachentwicklung genau zu charakterisieren und im Idealfall auf die nächste Phase zu bringen. Zum Beispiel scheint es mir, dass sich die Sprache hauptsächlich im „Polierstadium“ befindet. Wenn Sie weiterhin daran festhalten, dass die Phase der „Forschung“ noch nicht abgeschlossen ist, kann die Sprache mit abhängigen Typen, virtuellen Strukturen usw. angereichert werden, was interessant, aber kontraproduktiv wäre. Das Gegenteil ist auch der Fall: Wir können nicht genau formulieren, was in der grafischen Benutzeroberfläche fehlt. Daher führen vorzeitige Versuche, diese Suchvorgänge zu einer Standardlösung zu machen, wahrscheinlich zu suboptimalen Ergebnissen.

In vielen ausgereiften Produkten wechseln sich Releases ab, von denen einige der Ausführung neuer Funktionen gewidmet sind, während andere ihrer Stabilisierung gewidmet sind. Dies ist beispielsweise das Tick-tock-System von Intel. Die Android-Versionen von Kat Kit und Marshmallow waren stabil, während Lollipop aktiv schaufelte. Im Jahr 2018 wurde Rust mit vielen neuen Funktionen angereichert, daher glaube ich, dass die Zeit für die Stabilisierungsphase gekommen ist. Darin stimme ich Jonathan Turner sowie vielen anderen zu.

Rostsprache

Ich denke, im Großen und Ganzen ist die Rust-Sprache fertig. Es scheint, dass die Community eine Einigung über die Notwendigkeit erzielt hat, die Funktionen zu „landen“, die sich noch im laufenden Betrieb befinden (in Entwicklung): Wir sprechen von Async / Warten, konstanten Generika und einem Interpreter (der uns wahrscheinlich eine Überarbeitung ermöglichen wird) generische zugehörige Typen ). Ich denke jedoch, dass wir darüber hinaus nicht zu eifrig sein sollten, die Pipeline mit neuen Funktionen zu füllen.

Veränderung kostet Geld. Ab 2018 wurden zwei ausgezeichnete Bücher über Rust geschrieben, aber beide sind bereits etwas veraltet. Die Konventionen für die qualifizierten Pfade unterscheiden sich darin, jetzt verwenden wir dyn Trait usw. Je dynamischer die Änderungen sind, desto unangenehmer werden die Benutzer.

Es gibt viele Faktoren, die den Erfolg von Rust einschränken. Ich glaube nicht, dass die meisten dieser Mängel der Sprache selbst inhärent sind.

Takelage

Ein Rust Rig hätte viel besser sein können. Ich habe mit RLS experimentiert, bin aber immer zu einem normalen Texteditor und einer Befehlszeilenschleife zurückgekehrt (um ehrlich zu sein, habe ich solche Experimente in letzter Zeit nicht festgelegt). Ich denke, dass es auf lange Sicht erforderlich ist, die Rust-Werkzeuge erheblich zu modifizieren, um die Lernkurve zumindest irgendwie zu vereinfachen. Ich habe einige Ideen (ich hoffe, es ist Zeit, sie genauer zu erklären) über eine Gewächshaussprache, von der ich nicht sicher bin, wo dies machbar ist, wo es keinen klaren Unterschied zwischen dem Wert und der Verknüpfung dazu gibt, der Wert nach dem Umzug verwendet werden könnte usw. . Im Prinzip würde eine solche Sprache ermöglichen, dass eine Zeichenfolge als Zahl behandelt wird. Der Server akzeptiert in dieser Sprache geschriebene Programme, korrigiert sie schnell und konvertiert sie in einen vollwertigen Rust.

Natürlich entspricht RLS nur der Hälfte, Benutzer interagieren mit ihm über den Editor. Die Arbeit mit xi-editor ist praktisch, erfordert jedoch normalerweise eine Anleitung und Unterstützung. Diese Arbeit wurde von einer Community unter der Leitung von Colin Rofles durchgeführt . Ich bin nur froh zu sehen, wie sich dieser Editor verbessert (er ist bereits mein Hauptredakteur geworden). Es bietet Unterstützung für den Sprachserver sowie neue Funktionen, beispielsweise einen allgemeinen Anmerkungsmechanismus, der 2019 viel besser fertiggestellt wird.

Bibliotheksökosystem

Die heißeste Arbeit ist jetzt in vollem Gange, Bibliotheken für Rust zu erstellen. Unten liste ich die Dinge auf, die ich selbst tun möchte.

Eines der Themen, die ich ansprechen möchte, ist die „Kohärenz“, die meiner Meinung nach neben der technischen Komponente des Typsystems eines der wertvollsten Merkmale von Rust ist. Viele Komponenten der „Game Engine“ in C ++ sind eine sorgfältig vorbereitete Auswahl von Bibliotheken, die gut miteinander interagieren. Aber in Rust passieren viele dieser Dinge organisch. Container werden normalerweise für die Verwendung in Bundles geschärft, und wenn Sie Dinge wie into richtig verwenden, wird es umso besser. Ein besonders überzeugendes Beispiel der zweiten Art ist Minze , die die Interoperabilität vieler mathematischer Container gewährleistet, obwohl die Konventionen zur Definition von Vektortypen in ihnen nicht übereinstimmen.

SIMD

Ich denke, SIMD-Bibliotheken werden noch untersucht. Es gibt viele Wrapper-Bibliotheken, von denen jede eine etwas andere Perspektive und eine andere Reihe von Kompromissen bietet: simdeez , gepackter_simd , schneller und natürlich mein eigener furchtloser_simd . Diese Kompromisse sind keineswegs unbedingt erforderlich, da einige Benutzer die gesamte Leistung bis zum letzten Tropfen aus der Sprache herausholen müssen. Wenn Sie sich auf solche Extreme konzentrieren, müssen Sie auf die besten Anweisungen für bestimmte Prozessoren zurückgreifen. Andere werden Portabilität und Sicherheit zu schätzen wissen.

Einer der wichtigsten SIMD-Fehler ist, dass im Compiler viel mehr Arbeit geleistet werden muss, hauptsächlich für die Interaktion mit den SIMD-Architekturen AVX-512 und Nicht-x86. Es ist auch möglich, dass Wrapper-Bibliotheken einige Änderungen auf Sprachebene erfordern, um das Arbeiten so bequem wie möglich zu gestalten. Im Moment interagieren Einbettung und cfg(target_feature = ...) schlecht. Meiner Meinung nach ist dies ein weiteres Thema, das Forschung erfordert. Es ist interessant zu verstehen, wie weit wir ohne zusätzliche Unterstützung auf Sprachebene gehen können und welche genauen Funktionen dazu beitragen, den Komfort der Arbeit damit grundlegend zu erhöhen.

Audio

Es gibt praktische Audio-Container mit niedrigem Pegel, unter denen cpal besonders hervorzuheben ist. Es kann jedoch zu Schwierigkeiten bei der Leistung kommen (der Container verwendet nicht immer den Echtzeitstrom), einige Möglichkeiten. Es ist notwendig, den optimalen Weg zu finden: entweder cpal ändern oder einen neuen Container entwickeln, der bestimmte Probleme behebt. Insbesondere hierfür müssen Sie sich die C ++ - Bibliotheken, z. B. RtAudio , die diese Probleme gut lösen, genau ansehen.

Für die Audiosynthese auf höherer Ebene habe ich große Pläne für die Synthese von Rs . Diese Option ist nicht für jeden geeignet, aber ich denke, dies ist eine gute Grundlage für eine Vielzahl von Synthesetechniken und Audioeffekten. Es scheint, dass dieser Arbeitsbereich heute irgendwo zwischen den Stadien der Forschung und Entwicklung liegt.

Um dies zu verfolgen, lesen Sie den #synthesizer-Stream in unserem Zulip-Chat. Im November hielt ich einen Vortrag darüber, auf dessen Grundlage ich bald einen Beitrag schreiben möchte.

GUI

Grafische Benutzeroberflächen sind derzeit eine der Schwachstellen von Rust. Ich denke, dass wir 2019 in der Rust-Community viele Artikel zu diesem Thema sehen werden.
Persönlich scheint es mir, dass die Rostower GUIs nun der „Forschungsphase“ zugeordnet werden sollten. Viele alternative Ansätze werden erarbeitet, und bisher besteht kein Konsens darüber, welcher von ihnen der beste ist. Wie aktiv sollten 2D-Grafiken und andere Grundelemente der Benutzeroberfläche in der Systemarchitektur verwendet werden, oder sollten wir diesen gesamten Stapel selbst implementieren? Ist eine Bereitstellung im Web erforderlich (mithilfe von wasm)? Sollte der gesamte Programmierprozess als "Rust-native" wahrgenommen werden, oder ist es besser, sich an die Konventionen anzupassen, die in einer ausgereiften GUI festgelegt wurden? Verfügt die Rust-Community über genügend Ressourcen, um ein neues GUI-Toolkit zu erstellen, und wenn ja, lohnt es sich?

Ich habe ein Druidenprojekt gestartet, um eine GUI für meinen Synthesizer und mein Spiel zu erstellen, aber dieses Projekt ist ein Forschungsprojekt. Es präsentiert meinen Standpunkt, meine Antworten auf alle oben formulierten Fragen, und meiner Meinung nach entwickelt sich dieses Projekt gut. Aber ich wiederhole, dies ist ein Forschungsprojekt, und es wäre zu diesem Zeitpunkt sehr dumm, es in andere Projekte einzuführen.

Darüber hinaus laufen eine Reihe weiterer GUI-Entwicklungsprojekte. Meiner Meinung nach ist Azul am vielversprechendsten, weil ich WebRender als Grundlage für die Erstellung einer GUI mag. Ein weiteres vielversprechendes Projekt ist OrbTK , das auf der Basis von Redox erstellt wurde, jedoch plattformübergreifend und wirklich fortschrittlich ist. Sie können viel aus den Beispielen von Conrod , ggez sowie den Wrappern von Werkzeugen aus anderen Sprachen lernen.

Es überrascht nicht, dass die intensivste GUI-Entwicklungsaktivität in Rust eng mit Spielen zusammenhängt, und es scheint mir, dass dies gut ist. Innovationen haben im Gaming-Segment bessere Wurzeln, und der Bedarf an ausgereiften Tools ist hier nicht so groß. Sobald jedoch ein hervorragender Ansatz für die Implementierung der GUI in Rust erscheint, wird sie meiner Meinung nach die breiteste Anwendung finden. Ich stelle auch fest, dass mein Druide auf der Basis der GUI-Ebene aus dem xi-Client-Editor für Windows stammt .

Markup

Die Pulldown-Cmark-Bibliothek wird insbesondere für Rustdoc recht gut verwendet, ist jedoch in mancher Hinsicht veraltet. Seine Entwicklung hält nicht mit der Entwicklung der CommonMark-Spezifikation Schritt. Einer der Gründe, warum es ein wenig hängen geblieben ist, ist der Parsing-Algorithmus. Ich habe bereits eine Idee, wie ich einen neuen Algorithmus für diesen Zweck schreiben kann, viel besser als zuvor; Aber ich habe die Details noch nicht ausgearbeitet. Vor kurzem bin ich zu dieser Arbeit zurückgekehrt und bereite mich darauf vor, einen Algorithmus zu veröffentlichen. Wenn der Zweig new_algo zum Master hinzugefügt wird, sollte die Community meiner Meinung nach ihre weitere Entwicklung übernehmen und ihn mit neuen Funktionen bereichern. Ich denke über volle GFM-Kompatibilität, Mathematik und vielleicht noch etwas Ähnliches nach.

Vielen Dank an alle in der Rust-Community für die Fertigstellung der Sprache, mit der ich gerne lebe.