Wie gewünscht, hier meine Vorschläge für die Entwicklung von Rust ab 2019.

Ich muss sagen, dass ich nur für mich selbst spreche und nicht einmal ein sehr aktiver Teilnehmer am Projekt bin. Darüber hinaus beziehen sich diese Vorschläge weitgehend auf viele Projekte. Rost ist ein Sonderfall, aber er ist es, der jetzt zu einigen Gedanken führt.

Ich möchte auch darauf hinweisen, dass ich mit der Entwicklung von Rust im Allgemeinen zufrieden bin und dieser Vorschlag nur zur Aufrechterhaltung des weiteren Wohlstands gemacht wird, um einige der Probleme zu vermeiden, die ich jetzt von außen beobachte.

TL; DR: Es ist wichtig, das Problem anzuerkennen und explizite Mechanismen zu planen, um das Wachstum von zwei Dingen zu begrenzen:

1. Obligatorische allgemeine technische Artefakte, insbesondere die Definition einer Sprache.
2. Die Belastung für die an der Diskussion dieser Artefakte beteiligten Personen.

Insbesondere möchte ich auf die Unmöglichkeit und Unerwünschtheit eines unbegrenzten Wachstums in beide Richtungen hinweisen. Es gibt natürliche Grenzen. Wie in allen natürlichen Systemen, die an die Grenzen des Wachstums gestoßen sind, ist es besser, sich auf dieses Ereignis vorzubereiten und es kontrolliert und geplant durchzuführen.

Bitte beachten Sie, dass ich nicht über die Wachstumsgrenzen vieler anderer Bereiche schreibe. Zum Beispiel ein Paketindex, eine Site-Größe oder sogar eine Benutzergemeinschaft. Es ist nicht klar, welche Art von Bedrohung dies für Rust darstellt, daher sprechen wir oben nur über zwei spezifische Probleme.

Begrenzungsfaktoren und Flug

Jedes natürliche System hat Grenzen für das Wachstum. Deshalb ist das Universum (zum Beispiel) keine einzelne Amöbe, die sich mit Lichtgeschwindigkeit ausdehnt. Das System wächst (und oft wächst auch die Expansionsgeschwindigkeit!), Bis es auf begrenzende Faktoren stößt, und dann verlangsamt sich das Wachstum allmählich, bis die Gesamtsystemgröße ein Plateau erreicht. Typische Wachstumsmuster sehen in diesem Fall ungefähr wie ein Sigmoid oder eine „S-förmige Kurve“ aus und nähern sich allmählich einer Asymptote. Zumindest wenn begrenzende Faktoren allmählich und kontrolliert auftreten.



Wenn ein System unkontrolliert oder plötzlich auf ein Limit stößt, kann ein Phänomen auftreten, das eher einem Flug eines Ziels oder sogar einer Rückkehr ähnelt: Das Limit existiert immer noch, aber seine Wirkung wird eher als Zusammenbruch oder Krise empfunden. Die S-Kurve steigt auf einen Höhepunkt an, gefolgt von einem Zusammenbruch. Ich möchte das vermeiden.

Gute Kontrollbeispiele

Das Rust-Projekt verfügt über verschiedene Formen der Prozesssteuerung, die die Änderungs- und / oder Wachstumsrate im Wesentlichen begrenzen. Ich halte diese Maßnahmen für sehr vernünftig: Zum Teil dank ihnen ist das Projekt immer noch erfolgreich. In Analogie zu ihnen möchte ich die folgenden Empfehlungen formulieren. Aktuelle Managementformen:

• Die Bors-Warteschlange überspringt die Richtigkeitsänderungen für das Programm.
• Der Krater überspringt die Freigabe der Korrektheit des Ökosystems.
• Geplante Releases werden bevorzugt rechtzeitig veröffentlicht, auch wenn die geplante Funktion nicht bereit ist. Die Entscheidung wird pünktlich getroffen und alles Unvorbereitete wird abgeschnitten.

Darüber hinaus wurden innerhalb des Projekts wichtige soziale Strukturen geschaffen, um die Anzahl der Projektteilnehmer zu begrenzen.

• Verhaltenskodex . Nicht jeder erinnert sich, aber er postuliert nicht nur soziale Gerechtigkeit und so weiter. Es setzt auch Grenzen für das Signal-Rausch-Verhältnis in Gesprächen, nutzt die Aufmerksamkeit und die Zeit eines anderen aus und drängt auf Kompromisse (schließlich gibt nicht jede Lösung einen Nullbetrag an).
• RFC-Prozess . Regeln zu Form, Inhalt, Zeitpunkt, Einstellung von Teilnehmern, zulässigen und erwarteten Diskursformen bei der Erörterung wesentlicher Änderungen.
• Managementmodell . Abgrenzung der Verantwortlichkeiten, gegebenenfalls hierarchische Delegation, Rollen und Erwartungen der Teilnehmer und so weiter.

All dies ist im Wesentlichen die Erkenntnis, dass ohne Kontrolle Probleme und Krisen auftreten können: zumindest Chaos und Funktionsstörungen bis zu einem gewissen Grad. Wenn möglich, erfolgt die Kontrolle automatisch und völlig unparteiisch (um Unwillen und subjektive Einschätzung, die Versuchung, Abstriche zu machen usw. zu minimieren). Wenn Subjektivität nicht vermieden werden kann, werden zumindest die Regeln und Prozesse an gut dokumentierten, bekannten Stellen klar schriftlich formuliert. .

Problembereiche

Kehren wir zu zwei Problembereichen zurück, in denen das Projekt derzeit nicht über angemessene Mechanismen oder Richtlinien zur Kontrolle von Rust verfügt, die das Risiko einer möglichen Funktionsstörung oder sogar einer Krise bergen. In beiden Fällen ist nicht ganz klar, wie weit das Projekt von einer solchen Krise entfernt ist. In jedem Fall ist es jedoch besser, im Voraus zu handeln, als zu spät zu kommen.

1. Die Sprache selbst . Seine Definition. Dies ist (im Gegensatz zu vielen Teilen des Projekts) ein obligatorisches allgemeines technisches Artefakt. Jeder interessiert sich für ihn und jede Veränderung betrifft möglicherweise jeden. Darüber hinaus sollte jeder seinen wesentlichen Teil studieren und verstehen: Es ist unmöglich, uninteressante Teile zu ignorieren. Sogar das, was Sie ignorieren möchten , existiert in einem allgemeinen Kontext: Dokumentations- und Schulungsmaterialien, Testbeispiele und Testmaterial, interne Compilerkomponenten, formale Modelle, Codebasen, allgemeine Wartungslast usw.
   
   Hier wird das Wachstum der Sprache als Artefakt durch mindestens folgende Faktoren begrenzt:
   
   
   • Eine Gelegenheit für einen Anfänger, eine Sprache zu lernen.
   • Die Fähigkeit eines durchschnittlichen Benutzers, sich sicher zu fühlen und sich an die Codebasen anderer anzupassen.
   • Die Fähigkeit eines Experten oder Betreuers, alle (oder die meisten) Änderungen zu kennen.
   • Das Verhältnis von Kosten und Nutzen jeder neuen Änderung in Bezug auf neue und laufende Arbeiten. Die Anzahl der Personen oder Anwendungsfälle, die davon profitieren. Die Kosten sind in vielen Dimensionen des Designs und der Sprachgröße kombinatorisch. Sie nehmen fast immer zu.
   
   Wenn Sie diese Grenzwerte nicht einhalten, können Sie sehr ernsten Risiken ausgesetzt sein:
   
   
   • Unangemessene Sprachänderungen bis hin zur Unfähigkeit, kritische Sicherheitsgarantien aufrechtzuerhalten.
   • Reputation übermäßiger Komplexität, Verlust von Benutzern. Risiko, der nächste C ++ oder Haskell zu werden.
   • Schlechte Qualität mit unvollständiger Definition, Tests, Dokumentation.
   • Nicht ausgelastete Funktionen, die den Aufwand erfordern, der an anderer Stelle erforderlich ist.
   • Crushing in Dialekte, isolierte Programme, Wertminderung.
2. Die Belastung für die Menschen, die an der Sprache arbeiten. Einige Teile des Projekts können delegiert und auf alle verfügbaren Entwickler verteilt werden. Dies sind keine üblichen technischen Artefakte. Bis zu einem gewissen Grad müssen viele Menschen (und immer mehr) an fast allen Veränderungen teilnehmen. Dies bedeutet einen großen Druck auf alle in dieser Gruppe: Sie müssen alle Diskussionen verfolgen, und die Anzahl der Änderungen und die Anzahl der Teilnehmer an den Diskussionen wächst.
   
   Einige Einschränkungen für das Wachstum dieser Belastung für die Projektteilnehmer:
   
   
   • Die Anzahl der Stunden pro Tag.
   • Die Anzahl der bezahlten Stunden pro Tag.
   • Verantwortung und Interessen außerhalb des Projekts.
   • Eine Reserve an geistiger Energie, um zu verstehen, was passiert.
   • Vertrauen in die Meinung aller am Gespräch Beteiligten.
   • Eine Reserve psychologischer und emotionaler Energie zum Lesen und Diskutieren.
   • Vermutung von Treu und Glauben aller am Gespräch Beteiligten.
   
   Die Risiken einer Überschreitung dieser Grenzwerte sind möglicherweise ebenfalls sehr schwerwiegend:
   
   
   • Schlechte Entscheidungen aufgrund von Erschöpfung oder Burnout.
   • Wachsende Ungleichheit: Nur die privilegiertesten, erschwinglichsten, energischsten, gut bezahlten oder anderweitig gut organisierten Teilnehmer können alles im Auge behalten.
   • Eingrenzen des Diskurses: von sorgfältiger Überlegung bis zum „Gewinnen eines Streits“.
   • Die Leute spielen herum, brennen aus, benehmen sich schlecht, verlassen das Projekt.
   • Enttäuschung, Vorwurf der Unehrlichkeit, Ressentiments, verschwörerisches Denken, Gabeln.
   
   Ich möchte betonen, dass die beschriebenen Einschränkungen und Risiken nicht spezifisch für bestimmte Personen oder sogar das gesamte Rust-Projekt sind. In unterschiedlichem Maße sind sie überall zu finden. Das einfache Ersetzen der aktuellen Betreuer (zum Beispiel) durch die von Ihnen gewünschten wird das Problem nicht wirklich lösen: Die Einschränkungen bleiben bestehen. Die einzige Lösung ist ein durchdachtes Management bei einer Kollision mit einem Limit. Übernimm die Kontrolle.

Mögliche Steuerungsoptionen

Dies ist der schwierige Teil, in dem ich versuchen werde, eine klare Sprache zu vermeiden. Am Ende ist es wichtig, die Kontrolle über den eigenen freien Willen zu übernehmen und nicht von außen auferlegt zu werden. Ich denke, dass die Projektteilnehmer innehalten, reflektieren, gemeinsam überlegen und einige Kontrollen einrichten sollten. Daher werde ich nur einige mögliche Optionen anbieten, nicht sehr strukturiert, aber in festlicher Weihnachtsstimmung: als eine Reihe potenziell interessanter Geschenke zum Auspacken, Sehen und Entscheiden, Verlassen oder Tauschen gegen etwas Interessanteres.

1. Negativ definierter Raum . Nehmen Sie den Prozess der Diskussion von Funktionen und Konzepten aus Plänen für die zukünftige Entwicklung der Sprache. Erlauben (oder ermutigen) Sie den RFCs, die sagen, dass "Rust niemals X haben wird", für einen Wert von X. Wir erhalten also eine einmalige Runde für eine faire Diskussion und Berücksichtigung der Einwände gegen die langfristige Änderung ("nie" ist eine ziemlich lange Zeit!). Dann wird diese Diskussion für immer enden. Es wird keine ewige Quelle langwieriger Konflikte werden. Einige Beispiele, in denen negative Räume definiert sind:
   
   
   • bestimmte Ausdruckskategorien dauerhaft aus dem Typensystem entfernen (z. B. abhängige Typen, HKT usw.);
   • aus der Syntax (z. B. Parametertasten, Positions- oder benannte Argumente);
   • aus einer Reihe von Elementansichten (z. B. anonyme Beitragstypen);
   • von einer Reihe von Verpflichtungen zur Ausgabe an das mittlere Ende (z. B. Synthese von Konstanten, implizite Argumente).
   
   Setzen Sie einige strenge Einschränkungen: Vermeiden Sie diese Objekte sowie Personen, die sich das Ziel gesetzt haben, "alles richtig zu machen".
2. Entwicklungskosten müssen explizit angegeben werden. Machen Sie anhand einer Seite aus der Liste der Änderungen an WebAssembly deutlich, dass ein solcher RFC in einem frühen Stadium angemessene Investitionen in die Implementierung, Formalisierung, Überarbeitung der Dokumentation, Überarbeitung der Schulungsunterlagen, Schreiben von Tests, Wartung usw. erfordert. Wenn die Kosten zu diesem Zeitpunkt nicht gedeckt werden können Verschieben Sie Änderungen "bis ein Sponsor gefunden wird".
3. Setzen Sie sich Ziele für Lerngeschwindigkeit und Materialvolumen . Versuchen Sie, in die entgegengesetzte Richtung zu arbeiten: Gehen Sie von der Zeit und der Anzahl der Seiten aus, die erforderlich sind, um die Sprache zu lernen oder ein Experte darin zu werden - und löschen Sie dann alles, was über diesen Rahmen hinausgeht. Wenn "Rust in 21 Tagen lernen" nicht funktioniert, finden Sie das richtige Intervall. Drei Monate? Sechs? Jahr? Denken Sie an Sprachen, deren Lernen „definitiv zu viel Zeit in Anspruch nimmt“, und wählen Sie eine niedrigere Zahl. Ist das 1000-seitige Handbuch in Ordnung? 500? 300?
4. Legen Sie andere automatische Grenzwerte fest : die Anzahl der Codezeilen im Compiler, die Gesamtladezeit, US-Dollar pro Tag für AWS-Instanzen, die Anzahl der Regeln in der Grammatik, im Typensystem, den Prozentsatz der Testabdeckung, den Prozentsatz der Dokumente, die als "unvollständig" markiert werden können usw. Werden Sie kreativ, finden Sie die relevanten Dinge heraus, die messbar sind, und implementieren Sie dann Mechanismen, um sie zu begrenzen.
5. Persönliches Zeitlimit : Wie viele Stunden (oder bezahlte Zeit) eine Person wirklich ohne Erschöpfung oder Burnout einem Projekt widmen kann, einschließlich der Teilnehmer mit minimalen Rechten. Legen Sie ähnliche Einschränkungen für Gruppen, einzelne Releases und zugehörige Arbeitspläne fest. Entfernen oder verschieben Sie dann alles, was nicht in das Limit passt.
6. Ermöglichen Sie Moderatoren, die Häufigkeit von Posts zu begrenzen oder in bestimmten Diskussionen Ruhezeiten festzulegen . Manchmal scheint die Diskussion von außen zu heiß zu sein. Für die Deeskalation des Konflikts ist es einfacher, eine gemeinsame Grenze festzulegen, als Sanktionen gegen einzelne Teilnehmer zu verhängen.
7. Wie bei Moderatoren: Erstellen Sie ein zusätzliches projektübergreifendes Team, das an der Budgetierung und Prüfung der Lastniveaus in anderen Teams beteiligt ist . Es kann effektiv sein: Das Auditteam hilft den Mitarbeitern, bei Bedarf Nein zu sagen, und hält es nicht aus, wie die meisten Teammitglieder, zu viel zuzustimmen.

Dies sind nur einige Ideen in Richtung allgemeiner Wachstumsbeschränkungen. Ich bin sicher, dass Sie realistischere Möglichkeiten finden können, um die Einschränkungen hinsichtlich der Größe der Sprache und der persönlichen Belastung zu kontrollieren. Im Laufe der Jahre hat sich die Rust-Community als äußerst kreativ, aufgeschlossen und selbstkritisch erwiesen. Sie sollten dafür gelobt werden. Ich hoffe, dass dieser Artikel im gleichen Sinne konstruktiver Kritik angenommen wird.

Frohes Neues Jahr und viel Glück!