根据要求，这是我对2019年以后开发Rust的建议。
我必须说，我只是为自己说话，而且我甚至都不是该项目的积极参与者。 此外，这些建议在很大程度上与许多项目有关。 鲁斯特是一个特例，但正是他现在引起了一些思考。
我还应该指出，我总体上对Rust的开发感到满意，而提出此建议仅是为了保持进一步的繁荣，以避免我现在从外部观察到的一些问题。
TL； DR：重要的是要认识到问题并制定明确的机制来限制两件事的发展：
- 强制性的一般技术工件，尤其是一种语言的定义。
- 讨论这些工件的人员负担。
我尤其要提请注意双向无限增长的可能性和不希望之处。 有自然的限制。 正如在已达到增长极限的所有自然系统中一样，最好为该事件做好准备并以可控的计划方式进行。
请注意，我不是在写其他许多领域的增长限制。 例如，包索引，站点大小甚至用户社区。 目前尚不清楚这会对Rust造成什么样的威胁，因此我们仅在上面谈论两个具体问题。
限制因素和飞行
每个自然系统都有增长的极限。 这就是为什么宇宙不是（例如）单个变形虫以光速膨胀的原因。 系统会增长（并且通常扩展速度也会增长！），直到遇到限制因素，然后逐渐放缓，直到整个系统规模达到稳定状态。 在这种情况下，典型的生长方式看起来近似于S型或“ S形曲线”，逐渐接近渐近线。 至少如果限制因素以受控方式逐渐发生。
当系统以
不受控制的方式或
突然遇到限制时，可能会出现一种现象，看起来更像是目标的飞行甚至是返回：限制仍然存在，但其效果更像是崩溃或危机。 S曲线上升到峰值，然后崩溃。 我想避免这种情况。
良好的控制实例
Rust项目具有多种形式的过程控制，它们实质上限制了变化和/或增长的速度。 我认为这些措施是非常合理的：部分由于这些措施，该项目仍然成功。 以此类推，我想提出以下建议。 当前的管理形式：
- Bors队列跳过该程序的正确性更改。
- 火山口跳过了生态系统正确性的发布。
- 即使计划的功能尚未准备就绪， 计划的发布也希望按时发布。 决定是按时做出的，所有未做好的准备工作都将被取消。
此外，在项目内部创建了重要的社会结构，以限制项目参与者的数量。
- 行为准则 。 不是每个人都记得，但他不只是假定社会正义等等。 它还设置了对话中信噪比的限制，对他人注意力和时间的利用，并要求妥协（毕竟，并非每个解决方案都给出零值）。
- RFC流程 。 讨论重大变更时，有关形式，内容，时间，参与者招募，允许和期望的演讲形式的规则。
- 管理模式 。 职责划分，分层授权（必要时），参与者的角色和期望等。
实际上，所有这些都是在没有控制的情况下会发生麻烦和危机的认识：至少在一定程度上是混乱和功能失调。 如果可能的话，控制是自动且完全公正的（以最大程度地减少恶意和主观评估，偷工减料的诱惑等）。如果无法避免主观性，则至少应在有文件证明的众所周知的地方以书面形式清楚地制定规则和过程。 。
问题领域
让我们回到两个问题领域，该项目当前没有足够的机制或策略来控制Rust，这可能带来功能失调甚至危机的风险。 在这两种情况下，目前尚不清楚该项目距离这种危机有多远。 但是无论如何，提前行动总比迟到好。
- 语言本身 。 它的定义。 这（与项目的许多部分不同）是强制性的通用技术工件。 每个人都对他感兴趣，而每个变化都可能影响每个人。 而且，每个人都应该学习并理解其基本部分：不可能忽略无趣的部分。 甚至您要忽略的内容都存在于一般上下文中：文档和培训材料，测试示例和测试材料，内部编译器组件，形式模型，代码库，一般维护负担等。
在这里，语言作为人工产物的增长至少受到以下因素的限制：
- 初学者学习语言的机会。
- 普通用户具有自信，适应他人代码库的能力。
- 专家或维护人员了解所有（或大多数）更改的能力。
- 每个新变更的成本和收益在新的和正在进行的工作方面的比率。 受益于此的人数或用例。 在设计和语言大小的许多方面，成本是组合的。 它们几乎总是增加。
如果您不遵守这些限制，则可能面临非常严重的风险：
- 不合理的语言更改，直至无法维持重要的安全保证。
- 声誉过于复杂，用户流失。 成为下一个C ++或Haskell的风险。
- 质量功能差，定义，测试和文档不完整。
- 未充分利用的功能需要其他地方的努力。
- 挤入方言，孤立程序，降低价值。
- 使用该语言的人的负担 。 可以委派项目的某些部分，并将其分配给所有可用的开发人员。 这些不是常见的技术工件。 在某种程度上，许多人（越来越多） 必须参与几乎所有变更。 这意味着该组中的每个人都承受很大压力：他们必须关注所有讨论，并且变化的数量和讨论的参与者的数量都在增加。
对于项目参与者，此负载增长的一些限制：
- 每天的小时数。
- 每天的带薪小时数。
- 项目外的责任和利益。
- 有足够的精力去了解正在发生的事情。
- 对参与对话的每个人的意见充满信心。
- 具有阅读和讨论所需的心理和情感能量。
- 假定参与对话的每个人都具有真诚。
超过这些限制的风险也可能非常严重：
- 由于精疲力竭或倦怠而做出的错误决定。
- 日益加剧的不平等：只有最特权，负担得起，精力充沛，报酬丰厚或组织良好的参与者才能跟踪一切。
- 缩小讨论范围：从认真考虑到“赢得争议”。
- 人们无所事事，精疲力尽，表现不良，离开项目。
- 失望，不诚实，怨恨，阴谋思想，分叉。
我要强调的是，所描述的局限性和风险完全不是特定于特定人员甚至整个Rust项目所特有的。 在不同程度上，它们随处可见。 仅用您喜欢的维护者替换当前的维护者（例如）并不能真正解决问题：限制仍然存在。 唯一的解决方案是在有限的冲突中进行周到的管理。 控制住。
可能的控制选项
这是困难的部分，在这里我将尝试避免使用清晰的语言。 最后，重要的是要控制自己的自由意志，而不是由外界施加。 我认为项目参与者应该暂停，反思，集体考虑并建立一些控制措施。 因此，我将只提供几种可能的选项，这些选项不是非常结构化的，而是以节日圣诞节的精神：作为一堆可能有趣的礼物来打开，查看和决定，离开或交换更有趣的东西。
- 负定义的空间 。 从计划中讨论功能和概念的过程，以开发该语言。 允许（或鼓励）将X表示为“ Rust永远不会有X”的RFC。因此，我们进行了一次轮回，以进行公平的讨论并考虑对长期变更的反对意见（“ Never”很长一段时间！）。 这样的讨论将永远结束。 它不会成为持久冲突的永恒根源。 定义负空格的一些示例：
- 从类型系统中永久删除某些类型的表达（例如，从属类型，HKT等）；
- 来自语法（例如参数键，位置或命名参数）;
- 来自一组元素视图（例如，匿名帖子类型）；
- 从一组义务到输出到中间（例如，常量，隐式参数的合成）。
设置一些严格的限制条件：避免这些对象以及设定“正确地做一切”目标的人们。 - 开发费用需要明确说明。 从WebAssembly更改列表中的一页中清楚地表明，在早期阶段，这样的RFC将需要在实现，形式化，文档修订，培训材料修订，编写测试，维护等方面进行适当的投资。推迟更改“直到找到赞助商”。
- 设定学习速度和材料量的目标。 尝试朝相反的方向工作：从学习语言或成为语言专家所需的时间和页数着手-然后删除此框架之外的所有内容。 如果“在21天内学习Rust”无效，请找到正确的时间间隔。 三个月 六个？ 一年？ 想一想那些“绝对花费太多时间”学习的语言，然后选择一个较低的数字。 1000页手册可以吗？ 500？ 300？
- 设置其他自动限制 ：编译器中的代码行数，总加载时间，AWS实例每天的美元数，语法中的规则数，类型系统中的字符数，测试覆盖率的百分比，可以标记为“不完整”的文档的百分比等。发挥创造力，找出可衡量的相关事物，然后实施限制它们的机制。
- 个人时间限制 ：一个人可以真正花大约几个小时（或带薪时间）从事一个项目而不会用尽或精疲力尽，其中包括权利最小的参与者。 对组，个人发行版和相关工作计划设置类似的限制。 然后删除或推迟不符合限制的所有内容。
- 允许主持人设置帖子频率的限制或在特定讨论中设置沉默期 。 有时从外面看来，讨论太热了。 为了使冲突升级，建立共同的限制比对个别参与者实施制裁要容易得多。
- 与主持人一样：创建一个额外的跨项目团队，该团队参与预算和审核其他团队中的负载水平。 它可能是有效的： 审核团队会在必要时帮助人们说“不”，并且不会像大多数团队成员那样忍受，他们同意太多。
这些只是关于增长限制总体方向的一些想法。 我敢肯定，您可以提出更现实的方法来控制对语言大小和个人负担的限制。 多年来，Rust社区已被证明具有令人愉悦的创造力，思想和自我批评能力。 您应该为此赞扬。 我希望本文将以建设性批评的精神接受。
新年快乐，祝你好运！