Comme demandé, voici mes suggestions pour développer Rust à partir de 2019.

Je dois dire que je ne parle que pour moi, et je ne suis même pas un participant très actif au projet. De plus, ces propositions concernent dans une large mesure de nombreux projets. La rouille est un cas particulier, mais c'est lui qui mène maintenant à quelques réflexions.

Je dois également noter que je suis généralement satisfait du développement de Rust, et cette proposition n'est faite que dans le but de maintenir une plus grande prospérité afin d'éviter certains des problèmes que j'observe maintenant de l'extérieur.

TL; DR: Il est important de reconnaître le problème et de planifier des mécanismes explicites pour limiter la croissance de deux choses:

1. Objets techniques généraux obligatoires, en particulier la définition même d'une langue.
2. Le fardeau pour les personnes impliquées dans la discussion de ces artefacts.

En particulier, je veux attirer l'attention sur l'impossibilité et le caractère indésirable d'une croissance illimitée dans les deux sens. Il y a des limites naturelles. Comme dans tous les systèmes naturels qui ont atteint les limites de la croissance, il est préférable de se préparer à cet événement et de le conduire de manière contrôlée et planifiée.

Veuillez noter que je n'écris pas sur les limites de croissance de nombreux autres domaines. Par exemple, un index de package, la taille d'un site ou même une communauté d'utilisateurs. Le type de menace que cela représente pour Rust n'est pas clair, nous ne parlons donc que de deux problèmes spécifiques ci-dessus.

Facteurs limitatifs et fuite

Chaque système naturel a des limites à la croissance. C'est pourquoi l'Univers n'est pas (par exemple) une seule amibe qui se dilate à la vitesse de la lumière. Le système croît (et souvent la vitesse d'expansion augmente également!) Jusqu'à ce qu'il rencontre des facteurs limitants, puis progressivement la croissance ralentit jusqu'à ce que la taille globale du système atteigne un plateau. Les schémas de croissance typiques dans ce cas ressemblent approximativement à un sigmoïde ou à une «courbe en forme de S», se rapprochant progressivement d'une asymptote. Au moins si des facteurs limitants surviennent progressivement et de manière contrôlée.



Lorsqu'un système rencontre une limite de manière incontrôlée ou soudaine , un phénomène peut se produire qui ressemble plus à un vol d'une cible ou même à un retour: la limite existe toujours, mais son effet se fait davantage ressentir comme un effondrement ou une crise. La courbe en S atteint un sommet, suivi d'un effondrement. Je voudrais éviter cela.

De bons exemples de contrôle

Le projet Rust a plusieurs formes de contrôle des processus qui limitent essentiellement le taux de changement et / ou de croissance. Je pense que ces mesures sont très raisonnables: en partie grâce à elles, le projet est toujours réussi. Par analogie avec eux, je souhaite formuler les recommandations suivantes. Formes actuelles de gestion:

• La file d'attente Bors ignore les modifications de correction pour le programme.
• Le cratère ignore les versions correctes de l'écosystème.
• Il est préférable de publier les versions planifiées à temps, même si la fonctionnalité planifiée n'est pas prête. La décision est prise à temps et tout ce qui n'est pas préparé est interrompu.

De plus, d'importantes structures sociales ont été créées au sein du projet pour limiter le nombre de participants au projet.

• Code de conduite . Tout le monde ne se souvient pas, mais il ne postule pas seulement la justice sociale, etc. Il fixe également des limites sur le rapport signal / bruit dans les conversations, l'exploitation de l'attention et du temps de quelqu'un d'autre et pousse à des compromis (après tout, toutes les solutions ne donnent pas un montant nul).
• Processus RFC . Règles sur la forme, le contenu, le calendrier, le recrutement des participants, les formes de discours autorisées et attendues lors de l'examen des changements importants.
• Modèle de gestion . Délimitation des responsabilités, délégation hiérarchique, le cas échéant, rôles et attentes des participants, etc.

Tout cela, en substance, est la reconnaissance qu'en l'absence de contrôle, des troubles et des crises peuvent survenir: au moins le chaos et les dysfonctionnements dans une certaine mesure. Si possible, le contrôle est automatique et totalement impartial (pour minimiser la mauvaise volonté et l'évaluation subjective, la tentation de couper les coins, etc.) Si la subjectivité ne peut être évitée, au moins les règles et les processus sont clairement formulés par écrit, dans des endroits bien documentés et bien connus. .

Domaines problématiques

Revenons à deux zones problématiques où le projet ne dispose pas actuellement de mécanismes ou de politiques adéquats pour contrôler la rouille, qui comporte les risques d'un éventuel dysfonctionnement voire d'une crise. Dans les deux cas, la distance entre le projet et une telle crise n'est pas tout à fait claire. Mais en tout cas, il vaut mieux agir à l'avance que d'être en retard.

1. La langue elle-même . Sa définition. Ceci (contrairement à de nombreuses parties du projet) est un artefact technique commun obligatoire . Tout le monde s'intéresse à lui, et chaque changement affecte potentiellement tout le monde. De plus, chacun devrait étudier et comprendre sa partie essentielle: il est impossible d'ignorer les parties inintéressantes. Même ce que vous voulez ignorer existe dans un contexte général: documentation et supports de formation, exemples de test et matériel de test, composants internes du compilateur, modèles formels, bases de code, charge de maintenance générale, etc.
   
   Ici, la croissance du langage en tant qu'artefact est limitée par au moins les facteurs suivants:
   
   
   • L'occasion pour un débutant d'apprendre une langue.
   • La capacité de l'utilisateur moyen à se sentir en confiance, à s'adapter aux bases de code des autres.
   • La capacité d'un expert ou d'un mainteneur à connaître tous (ou la plupart) des changements.
   • Le rapport des coûts et des avantages de chaque nouveau changement en termes de travaux nouveaux et en cours. Le nombre de personnes ou de cas d'utilisation qui en bénéficient. Les coûts sont combinatoires dans de nombreuses dimensions de conception et de taille de langue. Ils augmentent presque toujours.
   
   Si vous ne respectez pas ces limites, vous pouvez faire face à des risques très graves:
   
   
   • Changements de langage déraisonnables, jusqu'à l'incapacité de maintenir des garanties de sécurité critiques.
   • Réputation de complexité excessive, perte d'utilisateurs. Risque de devenir le prochain C ++ ou Haskell.
   • Fonctions de mauvaise qualité avec définition incomplète, tests, documentation.
   • Des fonctionnalités sous-utilisées qui prennent l'effort nécessaire ailleurs.
   • Écrasement en dialectes, programmes isolés, réduction de valeur.
2. Le fardeau pour les personnes travaillant sur la langue. Certaines parties du projet peuvent être déléguées, réparties entre tous les développeurs disponibles. Ce ne sont pas des artefacts techniques courants. Dans une certaine mesure, de nombreuses personnes (et de plus en plus) doivent participer à presque tous les changements. Cela signifie beaucoup de pression sur tous les membres de ce groupe: ils doivent suivre toutes les discussions, et le nombre de changements et le nombre de participants aux discussions augmentent.
   
   Quelques restrictions sur la croissance de cette charge pour les participants au projet:
   
   
   • Le nombre d'heures par jour.
   • Le nombre d'heures payées par jour.
   • Responsabilité et intérêts extérieurs au projet.
   • Une réserve d'énergie mentale pour comprendre ce qui se passe.
   • Confiance dans l'opinion de toutes les personnes impliquées dans la conversation.
   • Une réserve d'énergie psychologique et émotionnelle pour la lecture et la discussion.
   • Présomption de bonne foi de toutes les personnes impliquées dans la conversation.
   
   Les risques de dépassement de ces limites sont également potentiellement très graves:
   
   
   • Mauvaises décisions prises à cause de l'épuisement ou de l'épuisement professionnel.
   • Inégalité croissante: seuls les participants les plus privilégiés, les plus abordables, les plus énergiques, les mieux payés ou autrement bien organisés peuvent garder une trace de tout.
   • Restreindre le discours: d'une réflexion approfondie à «gagner un différend».
   • Les gens s'amusent, s'épuisent, se comportent mal, quittent le projet.
   • Déception, accusation de malhonnêteté, ressentiment, pensée complice, fourchettes.
   
   Je tiens à souligner que les limites et les risques décrits ne sont absolument pas spécifiques à des personnes spécifiques ni même au projet Rust dans son ensemble. À des degrés divers, on les retrouve partout. Le simple remplacement des mainteneurs actuels (par exemple) par ceux que vous aimez ne résoudra pas vraiment le problème: les restrictions resteront. La seule solution est une gestion réfléchie en cas de collision avec une limite. Prenez le contrôle.

Options de contrôle possibles

C'est la partie difficile, où j'essaierai d'éviter un langage clair. En fin de compte, il est important de prendre le contrôle de son propre libre arbitre et non imposé de l'extérieur. Je pense que les participants au projet devraient faire une pause, réfléchir, réfléchir collectivement et établir des contrôles. Par conséquent, je ne proposerai que plusieurs options possibles, pas très structurées, mais dans un esprit festif de Noël: comme un tas de cadeaux potentiellement intéressants à déballer, voir et décider, partir ou échanger contre quelque chose de plus intéressant.

1. Espace défini négativement . Prenez le processus de discussion des fonctions et des concepts des plans pour le développement futur du langage. Autorisez (ou encouragez) les RFC qui disent que «Rust n'aura jamais X» pour une certaine valeur de X. Nous obtenons donc un tour unique pour une discussion équitable et une considération des objections au changement à long terme («jamais» est assez long!). Ensuite, cette discussion se terminera pour toujours. Il ne deviendra pas une source éternelle de conflits prolongés. Quelques exemples où des espaces négatifs sont définis:
   
   
   • supprimer définitivement certaines catégories d'expressivité du système de types (par exemple, types dépendants, HKT, etc.);
   • à partir de la syntaxe (par exemple, clés de paramètre, arguments positionnels ou nommés);
   • à partir d'un ensemble de vues d'éléments (par exemple, les types de messages anonymes);
   • d'un ensemble d'obligations de sortie vers le milieu de gamme (par exemple, synthèse de constantes, arguments implicites).
   
   Fixez-vous des restrictions strictes: éviter ces objets, ainsi que les personnes qui se sont fixé pour objectif de «tout faire correctement».
2. Les coûts de développement doivent être explicitement indiqués. En prenant une page de la liste des modifications apportées à WebAssembly, indiquez clairement qu'à un stade précoce, un tel RFC nécessitera des investissements appropriés dans la mise en œuvre, la formalisation, la révision de la documentation, la révision du matériel de formation, la rédaction des tests, la maintenance, etc. Si les coûts ne peuvent pas être couverts, à ce stade reporter les modifications "jusqu'à ce qu'un sponsor soit trouvé".
3. Fixez des objectifs d' apprentissage de la vitesse et du volume de matériel Essayez de travailler dans la direction opposée: procédez en fonction du temps et du nombre de pages nécessaires pour apprendre la langue ou pour en devenir un expert - puis supprimez tout ce qui dépasse ce cadre. Si "l'apprentissage de Rust en 21 jours" ne fonctionne pas, trouvez le bon intervalle. Trois mois? Six? Année? Pensez aux langues dont l'apprentissage "prend définitivement trop de temps" et choisissez un nombre inférieur. Le manuel de 1000 pages est-il correct? 500? 300?
4. Définissez d'autres limites automatiques : le nombre de lignes de code dans le compilateur, le temps de chargement total, les dollars par jour pour les instances AWS, le nombre de règles dans la grammaire, dans le système de type, le pourcentage de couverture de test, le pourcentage de documents pouvant être marqués comme "incomplets", etc. Faites preuve de créativité, découvrez les éléments pertinents qui sont mesurables, puis mettez en place des mécanismes pour les limiter.
5. Limite de temps personnelle : combien d'heures environ (ou de temps payé) une personne peut vraiment consacrer à un projet sans épuisement ni épuisement, y compris les participants avec des droits minimaux. Définissez des restrictions similaires sur les groupes, les versions individuelles et les plans de travail associés. Ensuite, supprimez ou repoussez tout ce qui ne rentre pas dans la limite.
6. Permettez aux modérateurs de fixer des limites sur la fréquence des messages ou de définir des périodes de silence dans des discussions spécifiques. Parfois de l'extérieur, il semble que la discussion soit trop chaude. Pour la désescalade du conflit, il est plus facile d'établir une limite commune que d'appliquer des sanctions à des participants individuels.
7. Comme avec les modérateurs: créez une équipe multi-projets supplémentaire qui est impliquée dans la budgétisation et l'audit des niveaux de charge dans d' autres équipes . Cela peut être efficace: l'équipe d'audit aidera les gens à dire non si nécessaire, et à ne pas endurer, comme la plupart des membres de l'équipe, en acceptant trop.

Ce ne sont que quelques idées dans le sens général des restrictions de croissance. Je suis sûr que vous pouvez trouver des moyens plus réalistes de prendre le contrôle des restrictions sur la taille de la langue et des charges personnelles. Au fil des ans, la communauté de Rust s'est révélée délicieusement créative, disposée et autocritique. Vous devriez être félicité pour cela. J'espère que cet article sera accepté dans le même esprit de critique constructive.

Bonne année et bonne chance!