كما هو مطلوب ، وإليك اقتراحاتي لتطوير Rust في 2019 وما بعده.

يجب أن أقول أنني أتحدث فقط عن نفسي ، وأنا لست مشاركًا نشطًا في المشروع. علاوة على ذلك ، تتعلق هذه المقترحات إلى حد كبير بالعديد من المشاريع. الصدأ هو حالة خاصة ، لكنه هو الآن الذي يؤدي إلى بعض الأفكار.

أود أن أشير أيضًا إلى أنني راضٍ بشكل عام عن تطور Rust ، وهذا الاقتراح مقدم فقط من أجل الحفاظ على المزيد من الرخاء ، لتجنب بعض المشاكل التي ألاحظها الآن من الخارج.

TL ؛ DR: من المهم الاعتراف بالمشكلة وخطة آليات واضحة للحد من نمو شيئين:

1. التحف الفنية العامة الإلزامية ، وخاصة تعريف اللغة.
2. العبء على الأشخاص المشاركين في مناقشة هذه القطع الأثرية.

على وجه الخصوص ، أود أن ألفت الانتباه إلى استحالة النمو غير المحدود وعدم رغبته في كلا الاتجاهين. هناك حدود طبيعية. كما هو الحال في جميع النظم الطبيعية التي وصلت إلى حدود النمو ، من الأفضل التحضير لهذا الحدث وإجرائه بطريقة منظمة ومخططة.

يرجى ملاحظة أنني لا أكتب عن حدود النمو في العديد من المجالات الأخرى. على سبيل المثال ، فهرس الحزمة أو حجم الموقع ، أو حتى مجتمع المستخدمين. ليس من الواضح نوع التهديد الذي يشكله هذا على روست ، لذلك نحن نتحدث فقط عن قضيتين محددتين أعلاه.

العوامل المحددة والطيران

كل نظام طبيعي له حدود للنمو. هذا هو السبب في أن الكون ليس (على سبيل المثال) أميبة واحدة تتسع بسرعة الضوء. ينمو النظام (وغالبًا ما تزداد سرعة التمدد أيضًا!) إلى أن يواجه العوامل المحددة ، ثم يتباطأ النمو تدريجياً حتى يصل الحجم الكلي للنظام إلى هضبة. تبدو أنماط النمو النموذجية في هذه الحالة تقريبًا مثل السيني أو "منحنى على شكل حرف S" ، وتقترب تدريجياً من بعض الخطوط المقربة. على الأقل إذا حدثت عوامل مقيدة تدريجيًا وبصورة محكومة.



عندما يواجه النظام حدًا بطريقة لا يمكن التحكم فيها أو فجأة ، قد تحدث ظاهرة تبدو وكأنها هروب لهدف أو حتى عائد: لا يزال الحد موجودًا ، لكن تأثيره يبدو وكأنه انهيار أو أزمة. يرتفع منحنى S إلى ذروته ، يليه الانهيار. أود تجنب هذا.

أمثلة جيدة السيطرة

يحتوي مشروع Rust على عدة أشكال للتحكم في العملية والتي تحد بشكل أساسي من معدل التغيير و / أو النمو. أعتقد أن هذه الإجراءات معقولة للغاية: جزئياً بفضلهم ، لا يزال المشروع ناجحًا. عن طريق القياس معهم ، أريد صياغة التوصيات التالية. الأشكال الحالية للإدارة:

• قائمة الانتظار Bors يتخطى التغييرات صحة البرنامج.
• الحفرة يتخطى إصدارات صحة النظام الإيكولوجي.
• يُفضل إصدار الإصدارات المخططة في الوقت المحدد ، حتى إذا كانت الميزة المخططة غير جاهزة. يتم اتخاذ القرار في الوقت المحدد ، ويتم قطع كل شيء غير مستعد.

بالإضافة إلى ذلك ، تم إنشاء هياكل اجتماعية مهمة داخل المشروع للحد من عدد المشاركين في المشروع.

• قواعد السلوك . لا يتذكر الجميع ، لكنه لا يفترض العدالة الاجتماعية وما إلى ذلك. كما أنه يضع قيودًا على نسبة الإشارة إلى الضوضاء في المحادثات ، واستغلال انتباه شخص آخر ووقته ، ويدفع إلى حلول وسط (في النهاية ، لا يعطي كل قرار مبلغًا صفريًا).
• عملية RFC . قواعد بشأن الشكل والمضمون وتوقيت وتوظيف المشاركين وأشكال الخطاب المسموح بها والمتوقعة عند مناقشة التغييرات المهمة.
• نموذج الإدارة . تحديد المسؤوليات ، التفويض الهرمي ، عند الضرورة ، أدوار وتوقعات المشاركين وما إلى ذلك.

كل هذا ، في جوهره ، هو إدراك أنه في حالة عدم وجود مشكلات وأزمات تحكم يمكن أن تحدث: على الأقل فوضى واختلالات وظيفية إلى حد ما. إذا كان ذلك ممكنًا ، يكون التحكم تلقائيًا ونزيهًا تمامًا (للتقليل إلى أدنى حد من سوء التقدير والتقييم الشخصي ، والإغراء بقطع الزوايا ، وما إلى ذلك). إذا لم يكن بالإمكان تجنب الذاتية ، فعلى الأقل يتم صياغة القواعد والعمليات كتابيًا ، في أماكن موثقة جيدًا. .

مجالات المشاكل

دعنا نعود إلى مجالين للمشاكل حيث لا يوجد للمشروع حاليًا آليات أو سياسات مناسبة للسيطرة على Rust ، والتي تحمل مخاطر خلل محتمل أو حتى أزمة. في كلتا الحالتين ، ليس من الواضح تمامًا إلى أي مدى يبعد المشروع الآن عن مثل هذه الأزمة. لكن على أي حال ، من الأفضل التصرف مقدمًا بدلاً من التأخير.

1. اللغة نفسها . تعريفه. هذا (على عكس أجزاء كثيرة من المشروع) هو قطعة فنية شائعة إلزامية . الجميع مهتم به ، وكل تغيير يحتمل أن يؤثر على الجميع. علاوة على ذلك ، يجب على الجميع دراسة وفهم الجزء الأساسي: من المستحيل تجاهل الأجزاء غير المفيدة. حتى ما تريد تجاهله موجود في سياق عام: وثائق ومواد التدريب ، أمثلة للاختبار ومواد الاختبار ، مكونات مترجم داخلي ، نماذج رسمية ، قواعد الشفرة ، عبء الصيانة العامة ، إلخ.
   
   هنا يقتصر نمو اللغة كأداة على الأقل بالعوامل التالية:
   
   
   • فرصة للمبتدئين لتعلم اللغة.
   • قدرة المستخدم العادي على الشعور بالثقة ، والتكيف مع قواعد كود الآخرين.
   • قدرة الخبير أو المشرف على معرفة كل التغييرات (أو معظمها).
   • نسبة التكاليف والفوائد لكل تغيير جديد من حيث العمل الجديد والمستمر. عدد الأشخاص أو حالات الاستخدام التي تستفيد منها. التكاليف متجانسة في العديد من أبعاد التصميم وحجم اللغة. هم دائما تقريبا زيادة.
   
   إذا لم تمتثل لهذه الحدود ، فيمكنك مواجهة مخاطر جسيمة:
   
   
   • التغييرات اللغوية غير المعقولة ، حتى عدم القدرة على الحفاظ على ضمانات الأمان الأساسية.
   • سمعة التعقيد المفرط ، وفقدان المستخدمين. خطر أن يصبح C ++ التالي أو Haskell.
   • وظائف ذات نوعية رديئة مع تعريف غير كامل والاختبارات والوثائق.
   • الميزات غير المستغلة التي تتطلب الجهد المطلوب في أي مكان آخر.
   • سحق في لهجات ، برامج معزولة ، تخفيض القيمة.
2. العبء على الأشخاص الذين يعملون على اللغة. يمكن تفويض بعض أجزاء المشروع وتوزيعها على جميع المطورين المتاحين. هذه ليست التحف الفنية المشتركة. إلى حد ما ، يتعين على العديد من الأشخاص (والمزيد والمزيد) المشاركة في جميع التغييرات تقريبًا . هذا يعني الكثير من الضغط على كل فرد في هذه المجموعة: يجب عليهم متابعة جميع المناقشات ، وعدد التغييرات وعدد المشاركين في المناقشات آخذ في الازدياد.
   
   بعض القيود على نمو هذا الحمل للمشاركين في المشروع:
   
   
   • عدد الساعات في اليوم الواحد.
   • عدد الساعات المدفوعة في اليوم.
   • المسؤولية والاهتمامات خارج المشروع.
   • احتياطي للطاقة الذهنية لفهم ما يحدث.
   • الثقة في رأي جميع المشاركين في المحادثة.
   • احتياطي من الطاقة النفسية والعاطفية للقراءة والمناقشة.
   • افتراض حسن النية لجميع المشاركين في المحادثة.
   
   من المحتمل أن تكون مخاطر تجاوز هذه الحدود خطيرة للغاية:
   
   
   • القرارات السيئة التي اتخذت بسبب الإرهاق أو الإرهاق.
   • تزايد عدم المساواة: يمكن فقط للمشاركين الأكثر امتيازًا ، وبأسعار معقولة ، وحيوية ، أو مدفوعة الأجر ، أو منظمة تنظيماً جيدًا تتبع كل شيء.
   • تضييق الخطاب: من دراسة متأنية إلى "كسب النزاع".
   • يخدع الناس حولها ، يحترقون ، يتصرفون بشكل سيء ، يتركون المشروع.
   • خيبة الأمل ، اتهام خيانة الأمانة ، والاستياء ، والتفكير التآمري ، الشوك.
   
   أريد أن أؤكد أن القيود والمخاطر الموصوفة ليست محددة تمامًا لأشخاص محددين أو حتى لمشروع الصدأ ككل. بدرجات متفاوتة ، تم العثور عليها في أي مكان. ببساطة استبدال المشرفين الحاليين (على سبيل المثال) بمن تحب لن يحل المشكلة حقًا: ستظل القيود. الحل الوحيد هو الإدارة المدروسة في تصادم مع حد. السيطرة.

خيارات التحكم الممكنة

هذا هو الجزء الصعب ، حيث سأحاول تجنب لغة واضحة. في النهاية ، من المهم السيطرة على إرادة الفرد الحرة ، وليس فرضها من الخارج. أعتقد أنه يجب على المشاركين في المشروع التوقف مؤقتًا عن بعض عناصر التحكم والتأمل فيها والنظر فيها بشكل جماعي. لذلك ، سأقدم فقط العديد من الخيارات الممكنة ، غير المنظمة للغاية ، ولكن بروح عيد الميلاد الاحتفالية: كمجموعة من الهدايا التي يحتمل أن تكون مثيرة للاهتمام لفكها أو رؤيتها أو اتخاذ قرار بشأنها أو تركها أو استبدالها بشيء أكثر إثارة للاهتمام.

1. مساحة محددة سلبا . خذ عملية مناقشة الوظائف والمفاهيم من خطط التطوير المستقبلي للغة. اسمح (أو شجع) RFCs التي تقول "Rust لن يكون لها أبدًا X" لبعض قيمة X. لذا ، فإننا نحصل على جولة لمرة واحدة لمناقشة عادلة والنظر في الاعتراضات على التغيير طويل الأجل ("لن يحدث أبدًا" وقت طويل جدًا!). ثم هذه المناقشة ستنتهي إلى الأبد. لن يصبح مصدرًا دائمًا للنزاع المطول. بعض الأمثلة التي يتم فيها تحديد المسافات السلبية:
   
   
   • إزالة فئات معينة من التعبيرية نهائيًا من نظام الكتابة (على سبيل المثال ، الأنواع التابعة ، HKT ، إلخ) ؛
   • من بناء الجملة (مثل مفاتيح المعلمات أو الوسائط الموضعية أو الوسائط المسماة) ؛
   • من مجموعة من طرق عرض العناصر (على سبيل المثال ، أنواع منشورات مجهولة) ؛
   • من مجموعة من الالتزامات إلى الإخراج إلى النهاية الوسطى (على سبيل المثال ، توليف الثوابت ، الحجج الضمنية).
   
   ضع بعض القيود الصارمة: لتجنب هذه الأشياء ، وكذلك الأشخاص الذين حددوا هدف "فعل كل شيء بشكل صحيح".
2. تكاليف التطوير يجب أن تكون صراحة. أخذ صفحة من قائمة التغييرات على WebAssembly ، أوضح أنه في مرحلة مبكرة ، سيتطلب مثل هذا RFC استثمارات مناسبة في التنفيذ ، وإضفاء الطابع الرسمي ، ومراجعة الوثائق ، ومراجعة مواد التدريب ، واختبارات الكتابة ، والصيانة ، وما إلى ذلك. إذا كانت التكاليف غير قابلة للتغطية ، في هذه المرحلة تأجيل التغييرات "حتى يتم العثور على الراعي."
3. حدد أهدافًا لسرعة التعلم وحجم المواد . حاول أن تعمل في الاتجاه المعاكس: تابع من مقدار الوقت وعدد الصفحات اللازمة لتعلم اللغة أو لتصبح خبيرًا فيها - ثم احذف كل شيء يتجاوز هذا الإطار. إذا لم تنجح "تعلم الصدأ في 21 يومًا" ، فابحث عن الفاصل الزمني الصحيح. ثلاثة اشهر؟ ستة؟ سنة؟ فكر في اللغات التي "يستغرق بالتأكيد الكثير من الوقت للتعلم" واختر عددًا أقل. هل دليل الصفحات 1000 موافق؟ 500؟ 300؟
4. قم بتعيين حدود تلقائية أخرى: عدد أسطر التعليمات البرمجية في برنامج التحويل البرمجي ، إجمالي وقت التحميل ، دولار يوميًا لمثيلات AWS ، عدد القواعد في القواعد ، في نظام الكتابة ، النسبة المئوية لتغطية الاختبار ، النسبة المئوية للمستندات التي يمكن تمييزها كـ "غير مكتملة" ، إلخ. كن مبدعًا ، واكتشف الأشياء ذات الصلة القابلة للقياس ، ثم قم بتنفيذ آليات للحد منها.
5. المهلة الزمنية الشخصية : كم ساعة تقريبًا (أو الوقت المدفوع) يمكن للشخص أن يكرسها حقًا لأي مشروع دون استنفاد أو نضوب ، بما في ذلك الحد الأدنى من الحقوق للمشاركين. ضع قيودًا مماثلة على المجموعات والإصدارات الفردية وخطط العمل ذات الصلة. ثم قم بإزالة أو تأجيل كل شيء لا يلائم الحد.
6. اسمح للمشرفين بوضع قيود على عدد مرات تكرار المشاركات أو تعيين فترات الصمت في مناقشات محددة. يبدو أحيانًا من الخارج أن النقاش حار جدًا. من أجل الحد من تصعيد النزاع ، من الأسهل وضع حد مشترك بدلاً من تطبيق العقوبات على المشاركين الأفراد.
7. كما هو الحال مع المشرفين: قم بإنشاء فريق إضافي متعدد المشروعات يشارك في إعداد مستويات تحميل الميزانية والرقابة في الفرق الأخرى . قد يكون ذلك فعالًا: سيساعد فريق التدقيق الأشخاص على قول لا عند الضرورة ، ولن يتحملوا ، كما يفعل معظم أعضاء الفريق ، الموافقة على الكثير.

هذه مجرد أفكار قليلة في الاتجاه العام لقيود النمو. أنا متأكد من أنه يمكنك التوصل إلى طرق أكثر واقعية للتحكم في القيود المفروضة على حجم اللغة والأحمال الشخصية. على مر السنين ، أثبت مجتمع Rust أنه مبهج وعقلي ومنتقد للذات. يجب أن تكون مدح لهذا. آمل أن يتم قبول هذه المقالة بنفس روح النقد البناء.

سنة جديدة سعيدة ونتمنى لك التوفيق!