私は自分のことだけを話していると言わなければならず、私はプロジェクトにあまり積極的に参加していません。 さらに、これらの提案は多くのプロジェクトに大きく関連しています。 さびは特別な場合ですが、今やいくつかの考えにつながるのは彼です。
また、一般的に私はRustの開発に満足しており、この提案は、現在私が外部から観察している問題の一部を回避するために、さらなる繁栄を維持するためにのみ行われていることにも注意する必要があります。
TL; DR：問題を認識し、次の2つのことの成長を制限する明示的なメカニズムを計画することが重要です。
- 必須の一般的な技術成果物、特に言語のまさに定義。
- これらのアーティファクトの議論に関与する人々の負担。
特に、両方向の無制限の成長の不可能性と望ましくないことに注意を喚起したいと思います。 自然な制限があります。 成長の限界に達したすべての自然システムと同様に、このイベントに備えて、管理された計画的な方法で実施することをお勧めします。
他の多くの分野の成長の限界について書いているわけではないことに注意してください。 たとえば、パッケージインデックス、サイトサイズ、またはユーザーコミュニティです。 これがRustにどのような脅威をもたらすかは不明であるため、現時点では上記の2つの特定の問題についてのみ説明しています。
制限要因と飛行
すべての自然システムには成長の限界があります。 そのため、宇宙は（たとえば）光速で膨張する単一のアメーバではありません。 システムは成長します（多くの場合、拡張速度も増加します！）制限要因に遭遇するまで、システムの合計サイズがプラトーに達するまで、成長は徐々に減速します。 この場合の典型的な成長パターンは、ほぼS字型または「S字型曲線」のように見え、漸近線に徐々に近づきます。 少なくとも制限要因が徐々に、制御された方法で発生する場合。
システムが制御されない方法で、または突然 、制限に達すると、ターゲットの飛行または帰還のように見える現象が発生する場合があります。制限はまだ存在しますが、その効果は崩壊または危機のように感じられます。 Sカーブがピークに達し、その後崩壊します。 これを避けたいです。
良い管理の例
Rustプロジェクトには、変更や成長のペースを本質的に制限するプロセス制御のいくつかの形式があります。 これらの対策は非常に合理的だと思います。それらのおかげもあって、プロジェクトはまだ成功しています。 それらとの類推により、次の推奨事項を策定します。 現在の管理形態：
- Borsキューは、プログラムの正確性の変更をスキップします 。
- クレーターは、エコシステムの正当性のリリースをスキップします。
- 計画された機能の準備が整っていない場合でも、計画されたリリースは時間どおりにリリースされることが推奨されます。 決定は時間通りに行われ、準備されていないものはすべて切断されます。
さらに、プロジェクト参加者の数を制限するために、プロジェクト内に重要な社会構造が作成されました。
- 行動規範 。 誰もが覚えているわけではありませんが、彼は社会正義などを仮定しているだけではありません。 また、会話の信号対雑音比に制限を設定し、他の人の注意と時間を活用し、妥協を促します（結局、すべての決定がゼロになるわけではありません）。
- RFCプロセス 。 フォーム、内容、タイミング、参加者の募集、重要な変更を議論する際の談話の許可および予想される形式に関するルール。
- 管理モデル 。 責任の説明、階層的な委任、必要に応じて、参加者の役割と期待など。
これはすべて、本質的に、コントロールがないとトラブルや危機が発生する可能性があるという認識です。少なくともある程度のカオスと機能障害です。 可能な場合、制御は自動的で完全に公平です（悪意や主観的評価、コーナーをカットする誘惑などを最小限に抑えるため）。主観性を回避できない場合、少なくとも規則とプロセスは、文書化されたよく知られた場所で明確に策定されます。
問題領域
Rustを制御するための適切なメカニズムやポリシーが現在プロジェクトにない2つの問題領域に戻りましょう。Rustは、機能不全や危機のリスクさえ抱えています。 どちらの場合も、プロジェクトが現在このような危機からどれだけ離れているかは完全には明らかではありません。 しかし、いずれにせよ、遅れるよりも事前に行動する方が良いです。
- 言語そのもの 。 その定義。 これは（プロジェクトの多くの部分とは異なり） 必須の共通技術成果物です。 誰もが彼に興味があり、あらゆる変化が潜在的にすべての人に影響を与えます。 さらに、誰もがその重要な部分を研究し、理解する必要があります。関心のない部分を無視することは不可能です。 無視したいものでさえ、一般的なコンテキストに存在します：ドキュメントとトレーニング資料、テスト例とテスト資料、内部コンパイラーコンポーネント、フォーマルモデル、コードベース、一般的なメンテナンス負荷など。
ここで、 アーティファクトとしての言語の成長は、少なくとも次の要因によって制限されます。
- 初心者が言語を学ぶ機会。
- 平均的なユーザーが自信を持ち、他の人のコードベースに適応する能力。
- すべての（またはほとんどの）変更を知るエキスパートまたはメンテナーの能力。
- 新規および進行中の作業に関して、各新規変更のコストと利点の比率。 それから利益を得る人々またはユースケースの数。 コストは、設計および言語サイズの多くの側面で組み合わせられます。 彼らはほとんど常に増加します。
これらの制限を遵守しない場合、非常に深刻なリスクに直面する可能性があります。
- 重要なセキュリティ保証を維持できないまでの、不合理な言語の変更。
- 過度の複雑さ、ユーザーの損失の評判。 次のC ++またはHaskellになるリスク。
- 定義、テスト、ドキュメントが不完全な低品質の機能。
- 他の場所で必要な努力を必要とする十分に活用されていない機能。
- 方言への粉砕、孤立したプログラム、価値の低下。
- その言語で働く人々の負担 。 プロジェクトの一部を委任し、利用可能なすべての開発者に配布できます。 これらは一般的な技術的成果物ではありません。 ある程度、多くの人々（そしてますます多くの人々） が ほとんどすべての変更に参加する必要があります。 これは、このグループの全員に大きなプレッシャーがかかることを意味します。彼らはすべての議論に従う必要があり、結局、変更の数と議論の参加者の数が増えています。
プロジェクト参加者のこの負荷の増加に関するいくつかの制限：
- 1日あたりの時間数。
- 1日あたりの有料時間数。
- プロジェクト外の責任と利益。
- 何が起こっているかを理解するための精神的なエネルギーの蓄え。
- 会話に関与したすべての人の意見に対する自信。
- 読書と議論のための心理的および感情的なエネルギーの蓄え。
- 会話に関与する全員の誠実さの推定。
これらの制限を超えるリスクも潜在的に非常に深刻です。
- 消耗または燃え尽きにより下された悪い決定。
- 不平等の拡大：最も特権があり、手頃な価格で、精力的で、給与が高い、またはその他の方法で組織化された参加者のみが、すべてを追跡できます。
- 談話の絞り込み：慎重な検討から「紛争に勝つ」まで。
- 人々は馬鹿になり、燃え尽き、振る舞わず、プロジェクトを去ります。
- 失望、不正の告発、res、陰謀的な思考、フォーク。
説明した制限とリスクは特定の人々やRustプロジェクト全体に完全に固有のものではないことを強調したいと思います。 さまざまな程度で、それらはどこでも見つかります。 現在のメンテナーを（たとえば）好きなメンテナーに置き換えるだけでは、実際に問題を解決することはできません。制限は残ります。 唯一の解決策は、制限との衝突における思慮深い管理です。 コントロールしてください。
可能な制御オプション
これは難しい部分であり、明確な言葉遣いを避けようとします。 最後に、自分の自由意志を管理することが重要であり、外部から課されることはありません。 プロジェクトの参加者は、一時停止し、反映し、集合的に検討し、いくつかのコントロールを確立する必要があると思います。 したがって、私はいくつかの可能なオプションを提供しますが、非常に構造化されたものではなく、お祝いのクリスマスの精神です：潜在的に興味深いギフトの束として、それらを展開し、見たり、もっと面白いものと交換するかどうかを判断します。
- 負に定義されたスペース 。 言語の将来の開発のための計画から機能と概念を議論するプロセスを取ります。 Xのある値に対して、「Rustは決してXを持たない」と言うRFCを許可（または推奨）します。したがって、長期的な変更に対する異議の公正な議論と検討のために1回限りのラウンドを取得します（「決して」はかなり長い時間です！）。 そして、この議論は永遠に終わります。 それは長引く紛争の永遠の源にはなりません。 負の空間を定式化できるいくつかの例：
- 型システムから表現力の特定のカテゴリ（たとえば、依存型、HKTなど）を完全に削除します。
- 構文から（例：パラメータキー、位置引数または名前付き引数）;
- 一連の要素ビュー（たとえば、匿名の投稿タイプ）から。
- ミドルエンドに出力する義務のセットから（たとえば、定数の合成、暗黙的な引数）。
いくつかの厳しい制限を設定します。これらのオブジェクト、および「すべてを正しく行う」という目標を設定した人々を回避します。 - 開発コストを明示的に述べる必要があります。 WebAssemblyの変更リストからページを取得し、早い段階で、そのようなRFCが実装、形式化、ドキュメントの改訂、トレーニング資料の改訂、テストの作成、メンテナンスなどに適切な投資を必要とすることを明確にします。 「スポンサーが見つかるまで」変更を延期します。
- 学習速度と教材の量の目標を設定します。 逆の方向で作業してみてください。言語を習得するか、言語の専門家になるために必要な時間とページ数から進んでください-そして、このフレームワークを超えるすべてを削除します。 「21日でRustを学習する」が機能しない場合は、適切な間隔を見つけてください。 3ヶ月？ 六？ 年？ 学習に「明らかに時間がかかりすぎる」言語を考え、より少ない数を選択します。 1000ページのマニュアルは大丈夫ですか？ 500？ 300？
- その他の自動制限を設定します 。コンパイラのコード行数、合計ロード時間、AWSインスタンスの1日あたりのドル数、文法のルール数、型システム、テストカバレッジの割合、「不完全」とマークできるドキュメントの割合など創造性を発揮し、測定可能な関連事項を把握してから、それらを制限するメカニズムを実装します。
- 個人的な時間の制限 ：最小限の権限を持つ参加者を含め、疲労や燃え尽きなしで、プロジェクトに実際に専念できる時間（または支払われた時間） グループ、個々のリリース、および関連する作業計画に同様の制限を設定します。 次に、制限に収まらないすべてのものを削除または延期します。
- モデレーターが投稿の頻度に制限を設定したり、特定のディスカッションで沈黙の期間を設定したりできます 。 時々、外からは議論が暑すぎるようです。 紛争のエスカレーション解除については、個々の参加者に制裁を適用するよりも、共通の制限を設定する方が簡単です。
- モデレーターと同様に、 他のチームの負荷レベルの予算編成と監査に関与する追加のプロジェクト間チームを作成します。 効果的である可能性があります。 監査チームは、ほとんどのチームメンバーのように、必要なときに人々がノーと言うのを助け、あまりにも同意します。
これらは、成長制限の一般的な方向性に関するいくつかのアイデアにすぎません。 言語のサイズと個人の負荷の制限を制御するためのより現実的な方法を思いつくことができると確信しています。 長年にわたり、Rustコミュニティは、楽しく創造的で、精神的で、自己批判的であることが証明されています。 あなたはこれを称賛されるべきです。 この記事が建設的な批判と同じ精神で受け入れられることを願っています。
明けましておめでとうございます！