الزملاء ، مساء الخير للجميع!
يسرنا أن نقدم لكم ترجمة لمقال برنامجي حقيقي من
راف ليفين ، الذي يثير عمله العملاق في تطوير لغة الصدأ الاحترام والتقديس:
دون تواضع زائف وبدون كراهية ، استجاب مؤلف محترم بموضوعية وحماس لنداء مجتمع الصدأ ، الذي تم نشره بالرجوع إليه في بداية هذا المقال. نأمل أن اتضح أنها مثيرة للاهتمام وتؤكد الحياة.
في الآونة الأخيرة ،
اقترح فريق Rust Core Team
كتابة مقالات مع آراء حول كيفية نمو Rust في عام 2019. هذا هو رأيي.
دورة حياة النضوجفي هذه المقالة سأنظر في دورة حياة النضوج بشكل مبسط للغاية. دعها تتكون من ثلاث مراحل فقط: البحث ، التطوير ، التلميع. تختلف عناصر الصدأ المختلفة في درجاتها المختلفة من النضج. من المهم أخذ ذلك في الاعتبار عند محاولة تحديد المرحلة الحالية لتطور اللغة بدقة ، وبشكل مثالي ، إيصالها إلى المرحلة التالية. على سبيل المثال ، يبدو لي أن اللغة هي أساسًا في مرحلة "التلميع". إذا استمرت في حقيقة أن مرحلة "البحث" لم تكتمل بعد ، فيمكن إثراء اللغة بأنواع تابعة ،
وهياكل افتراضية ، وما إلى ذلك ، الأمر الذي سيكون مثيراً للاهتمام ولكنه سيؤدي إلى نتائج عكسية. يكون العكس صحيحًا أيضًا: لا يمكننا صياغة ما نفتقده تمامًا في واجهة المستخدم الرسومية ، لذلك من المحتمل أن تؤدي المحاولات المبكرة لجلب عمليات البحث هذه إلى حل قياسي إلى نتائج دون المستوى الأمثل.
في العديد من المنتجات الناضجة ، يتم إطلاق الإصدارات البديلة ، والتي يكرس بعضها للتشغيل في ميزات جديدة ، بينما يكرس البعض الآخر لتحقيق الاستقرار فيها. هذا ، على سبيل المثال ، هو نظام Intel to-to-tock. كانت إصدارات Android Kit من Kat Kit و Marshmallow مستقرة ، بينما كان Lollipop يعمل بنشاط على التجريف). في عام 2018 ، تم إثراء Rust بالعديد من الميزات الجديدة ، لذلك أعتقد أن الوقت قد حان لمرحلة الاستقرار. في هذا أتفق مع
جوناثان تيرنر ، وكذلك مع العديد من الآخرين.
لغة الصدأأعتقد ، إلى حد كبير ، أن لغة الصدأ جاهزة. يبدو أن المجتمع قد وافق على الحاجة إلى "الهبوط" تلك الميزات التي لا تزال "قيد التشغيل" (قيد التطوير): نحن نتحدث عن المزامنة / في انتظار ، والأدوار الجنيسة ، والمترجم الشفهي (الذي من المرجح أن يوفر لنا مراجعة
أنواع المرتبطة العامة ). ومع ذلك ، أعتقد أنه علاوة على ذلك ، يجب ألا نكون متحمسين للغاية في ملء خط الأنابيب بميزات جديدة.
تغيير تكاليف المال. اعتبارًا من عام 2018 ، تم كتابة كتابين ممتازين عن الصدأ ، لكن كلاهما قديم بالفعل. تختلف اتفاقيات المسارات المؤهلة فيها ، والآن نستخدم
dyn Trait ، إلخ. كلما كانت التغييرات أكثر ديناميكية ، زاد إزعاج المستخدمين.
هناك العديد من العوامل التي تحد من نجاح الصدأ. لا أعتقد أن معظم أوجه القصور هذه متأصلة في اللغة نفسها.
تزويريمكن أن يكون تلاعب الصدأ أفضل بكثير. لقد جربت RLS ، لكنني دائمًا ما عدت إلى محرر نصوص عادي وحلقة سطر أوامر (بصراحة ، لم أقم بتعيين هذه التجارب مؤخرًا). أعتقد أنه على المدى الطويل ، يجب تعديل أدوات Rust بشكل ملحوظ لتخفيف منحنى التعلم على الأقل بطريقة أو بأخرى. لدي بعض الأفكار (آمل أن يكون هناك وقت لشرحها بمزيد من التفصيل) حول لغة الدفيئة ، التي لست متأكدًا من حيث يمكن تنفيذها ، حيث لن يكون هناك فرق واضح بين القيمة والارتباط بها ، يمكن استخدام القيمة بعد النقل ، إلخ. . من حيث المبدأ ، فإن مثل هذه اللغة تسمح بمعالجة السلسلة كرقم. يقبل الخادم البرامج المكتوبة بهذه اللغة ، ويقوم بتصحيحها بسرعة وتحويلها إلى Rust كاملة.
بطبيعة الحال ، RLS فقط نصف يتوافق مع هذا ، يتفاعل المستخدمون معها من خلال المحرر. يعد العمل مع
xi-editor أمرًا ملائمًا ، رغم أنه يتطلب عادة بعض التوجيه والدعم. تم تنفيذ هذا العمل من خلال مجتمع بقيادة
كولين روفليس ، ويسعدني أن أرى كيف يتحسن هذا المحرر (أصبح بالفعل محرري الرئيسي). يوفر الدعم لخادم اللغة ، فضلاً عن الميزات الجديدة ، على سبيل المثال ، آلية التعليق العام ، والتي سيتم الانتهاء منها بشكل أفضل في عام 2019.
النظام البيئي للمكتبةالعمل الأكثر سخونة الآن على قدم وساق في إنشاء مكتبات للصدأ. أدرج أدناه الأشياء التي أخطط للقيام بها بنفسي.
أحد الموضوعات التي أود طرحها هو "التماسك" ، والذي ، في رأيي ، هو واحد من أهم ميزات Rust ، إلى جانب
المكون التقني لنظام النوع الخاص به . تعد العديد من مكونات "محرك اللعبة" ضمن C ++ مجموعة مختارة بعناية من المكتبات التي تتفاعل جيدًا مع بعضها البعض. لكن في راست ، تحدث العديد من هذه الأشياء بشكل عضوي. عادةً ما يتم تشديد الحاويات حقًا للاستخدام في الحزم ، وإذا كنت تستخدم أشياء مثل بشكل صحيح ، فسيصبح الوضع أفضل. ومن الأمثلة المقنعة بشكل خاص من النوع الثاني
النعناع ، والذي يضمن قابلية التشغيل البيني للعديد من الحاويات الرياضية ، على الرغم من أن الاتفاقيات المستخدمة لتعريف أنواع المتجهات لا تتزامن معها.
SIMDأعتقد أن مكتبات SIMD لا تزال قيد التحقيق. هناك العديد من مكتبات
المجمعات ، تقدم كل واحدة منها منظوراً مختلفاً قليلاً ومجموعة مختلفة من المقايضات:
simdeez ، و
pack_simd ،
وأسرع ، وبالطبع ، my
fear_simd الخاص بي. هذه التنازلات بعيدة عن أن تكون غير مشروطة ، لأن بعض المستخدمين سيحتاجون إلى الضغط على جميع الأداء من اللغة حتى آخر إسقاط ، وإذا كنت تنجذب إلى مثل هذه الحالات القصوى ، فسوف يتعين عليك اللجوء إلى أفضل الإرشادات لمعالجات محددة. سوف نقدر الآخرين قابلية والأمن.
أحد أهم أخطاء SIMD هو أن هناك حاجة إلى مزيد من العمل في المحول البرمجي ، إلى حد كبير للتفاعل مع بنيات SIMX AVX-512 وغير x86. من الممكن أيضًا أن تتطلب مكتبات مجمّع بعض التغييرات على مستوى اللغة لجعل العمل مريحة قدر الإمكان ؛ لذا ، في الوقت الحالي ،
cfg(target_feature = ...) التضمين و
cfg(target_feature = ...) بشكل سيئ. في رأيي ، هذه قضية أخرى تتطلب البحث. من المثير للاهتمام أن نفهم إلى أي مدى يمكننا أن نذهب بدون دعم إضافي على مستوى اللغة ، وما هي الميزات بالضبط التي ستساعد على زيادة راحة العمل بشكل أساسي؟
الصوتهناك حاويات صوتية مريحة منخفضة المستوى ، من بينها
cpal ينبغي الإشارة إليه بشكل خاص. ومع ذلك ، قد تكون هناك صعوبات في ذلك على مستوى الأداء (الحاوية لا تستخدم دفق الوقت الفعلي دائمًا) ، بعض الاحتمالات. من الضروري العثور على الطريقة المثلى: إما تعديل cpal ، أو تطوير حاوية جديدة من شأنها حل مشكلات محددة. لهذا ، على وجه الخصوص ، تحتاج إلى النظر بعناية في مكتبات C ++ ، على سبيل المثال ،
RtAudio ، التي تحل هذه المشكلات جيدًا.
لتوليف الصوت على مستوى أعلى ، لدي خطط كبيرة
لتجميع - rs . هذا الخيار غير مناسب للجميع ، لكنني أعتقد أن هذا يعد أساسًا جيدًا لمجموعة متنوعة من تقنيات التوليف والمؤثرات الصوتية. يبدو أن مجال العمل هذا اليوم يقع بين مراحل البحث والتطوير.
لمتابعة هذا الأمر ، تحقق من
تدفق #synthesizer في دردشة Zulip. في نوفمبر / تشرين الثاني ، ألقيت محاضرة حول هذا الموضوع ، وعلى أساس ذلك أخطط لكتابة منشور قريبًا.
واجهة المستخدم الرسوميةتعد واجهات المستخدم الرسومية حاليًا واحدة من أضعف نقاط Rust. أعتقد أنه في عام 2019 ، سنرى الكثير من المقالات حول هذا الموضوع في مجتمع Rust.
شخصيا ، يبدو لي أن واجهات المستخدم الرسومية روستوف ينبغي الآن أن يعزى إلى مرحلة "البحث". يتم وضع العديد من الأساليب البديلة ، وحتى الآن لا يوجد توافق في الآراء حول أي منها هو الأفضل. ما مدى فعالية استخدام رسومات ثنائية الأبعاد وغيرها من بدائل واجهة المستخدم في بنية النظام ، أو هل يجب أن ننفذ هذه المجموعة بالكامل لوحدنا؟ هل النشر على الويب ضروري (باستخدام wasm)؟ هل يجب اعتبار عملية البرمجة بأكملها "أصيلة الصدأ" ، أم أنه من الأفضل أن تتكيف مع الاتفاقيات الموضوعة في بعض واجهة المستخدم الرسومية الناضجة؟ هل لدى مجتمع Rust موارد كافية لإنشاء مجموعة أدوات جديدة من واجهة المستخدم الرسومية ، وإذا كان الأمر كذلك ، فهل يستحق كل هذا العناء؟
لقد بدأت مشروع
Druid لإنشاء واجهة المستخدم الرسومية الخاصة بي المزج ولعب ، ولكن هذا المشروع هو أحد البحوث. إنه يقدم وجهة نظري وإجاباتي على جميع الأسئلة الواردة أعلاه ، وفي رأيي أن هذا المشروع يتطور بشكل جيد. ولكن ، أكرر ، هذا مشروع بحثي ، وسيكون من الغباء للغاية في هذه المرحلة إدخاله في مشاريع أخرى.
بالإضافة إلى ذلك ، هناك عدد من مشاريع تطوير واجهة المستخدم الرسومية الأخرى قيد التنفيذ. في رأيي ، فإن أكثرها واعدة هو
Azul ، لأنني أحب WebRender كأساس لبناء واجهة المستخدم الرسومية. هناك مشروع آخر واعد جدًا وهو
OrbTK ، الذي تم
إنشاؤه على أساس Redox ، ولكن عبر نظام
أساسي ومتقدم حقًا. يمكنك أن تتعلم الكثير من أمثلة
Conrod ،
ggez ، وكذلك أدوات تغليف اللغات الأخرى.
مما لا يثير الدهشة ، أن نشاط تطوير واجهة المستخدم الرسومية الأكثر كثافة في Rust يرتبط ارتباطًا وثيقًا بالألعاب ، ويبدو لي أن هذا أمر جيد. تتجذر الابتكارات بشكل أفضل في قطاع الألعاب ، والحاجة إلى الأدوات الناضجة ليست حادة للغاية هنا. ولكن بمجرد ظهور نهج ممتاز لتنفيذ واجهة المستخدم الرسومية في Rust ، أعتقد أنه سيجد أوسع تطبيق. وألاحظ أيضًا أن Druid الخاص بي قد نشأ على أساس مستوى واجهة المستخدم الرسومية من
محرر عميل xi لنظام التشغيل Windows .
العلاماتيتم استخدام
المكتبة المنسدلة بشكل جيد ، خاصة بالنسبة لل rustdoc ، ولكن يتم إهمالها في بعض النواحي. تطورها لا تواكب تطوير مواصفات CommonMark. أحد الأسباب وراء حصولها على مشكلة صغيرة هو استخدام خوارزمية التحليل ؛ لدي بالفعل فكرة عن كيفية كتابة خوارزمية جديدة لهذا الغرض ، أفضل بكثير من ذي قبل ؛ لكنني لم أضع التفاصيل بعد. لقد
عدت مؤخرًا
إلى هذا العمل وأستعد لإطلاق خوارزمية. عند
new_algo فرع
new_algo إلى الرئيسي ، أعتقد أنه يجب على المجتمع مواصلة تطويره وإثرائه بميزات جديدة. أنا أفكر في توافق GFM الكامل ، والرياضيات ، وربما شيء آخر من هذا القبيل.
شكرًا للجميع في مجتمع Rust على الانتهاء من اللغة التي أستمتع بها.