هل ستستفيد المنصة بشكل كبير من سلامة الذاكرة؟
يمكن أن يشهد الأداء أيضًا تحسنًا.
أعتقد أيضًا أنه يمكن تقليل أخطاء المناقشة التي لا تنتهي باستخدام Rust.
هل سيستمر Discourse كمنصة حديثة دون إعادة كتابته بلغة Rust؟
مع سهولة وكفاءة عمل Rust، لا ينبغي أن تكون العمالة مشكلة.
أفكار؟
هل تتطوع لنقله؟ 
كتب جيف مقالة مدونة حول سبب اختيار روبي:
من المحتمل أن تكون قد كُتبت قبل رست (نعم)، ولكنها بالتأكيد ستقدم بعض التبريرات.
بالتأكيد، لكن مايكروسوفت تسير في نفس اتجاه Rust أيضًا.
جيف يعرف بالتأكيد الآن أن Rust أفضل.
يمكن القيام بذلك في 12-16 يومًا ببعض العرق والدموع. إنه صغير جدًا على التقاعد بعد.
أنا متأكد من أن الأمر يستغرق 12-16 يومًا على الأقل للترقية إلى إصدار جديد من Ruby أو postgres. هناك حوالي 60 ألف سطر من Ruby.
ما الذي سيحل محل Rails؟
تمتلك Microsoft موارد وجيوبًا عميقة جدًا.
واحد ستحتاج إلى إعادة كتابة النواة وجميع الإضافات أيضًا.
هذا يعني أيضًا أن خارطة الطريق ستحتاج إلى تعليق.
هل يمكن القيام بذلك بالتأكيد. ولكنك تحتاج أيضًا إلى الاختبار وتصحيح الأخطاء.
من المرجح أن تتعطل مواقع العملاء الحاليين لـ discourse.
في رأيي، إذا كان الفريق سيعمل على هذا. ستحتاج إلى العمل عليها كفرع مع مختبري بيتا على مدى فترة طويلة. نسخ الإضافات لـ Discourse2 Meta على سبيل المثال.
لذلك ليس من المحتمل أن يكون من المعقول في هذا الوقت تقسيم الموارد للحفاظ على روبي الحالي والنقل.
عذرًا، هل هذا خطأ مطبعي، هل قصدت أشهر؟
هل يمكنك الإشارة إلى مشروع واحد بحجم ونطاق مماثلين لـ Discourse حيث تم تحقيق مثل هذا النقل في مثل هذا الإطار الزمني القصير؟
أراهن أن العملية التي يحددها ديفيد ميجنسون تبدو مألوفة بشكل رهيب:
يلاحظ مطورو النخبة (الخبراء) أن هناك الكثير من العامة يستخدمون لغة البرمجة الحالية الخاصة بهم، ويبدأون في البحث عن شيء يميزهم بشكل أفضل عن زملائهم المتوسطين.
يأخذ مطورو النخبة قائمة التسوق الخاصة بهم بالمضايقات الحالية ويبحثون عن لغة جديدة وغير معروفة يبدو أنها تحتوي على عدد أقل منها.
يبدأ مطورو النخبة في قيادة تطوير اللغة الجديدة، والمساهمة بالكود، وكتابة المكتبات، وما إلى ذلك، ثم يبشرون باللغة الجديدة. يتبع المطورون دون النخبة (المخضرمون) مطوري النخبة إلى اللغة الجديدة، مما يخلق سوقًا للكتب والتدريب وما إلى ذلك، ويسرع أيضًا من تطوير واختبار اللغة.
يبدأ المطورون دون النخبة، الذين لديهم تأثير هائل (يميل مطورو النخبة إلى العمل في عزلة على مشاريع بحثية بدلاً من فرق التطوير الإنتاجية)، في الدفع نحو اللغة الجديدة في مكان العمل.
تدرك الكتلة الضخمة من المطورين العاديين أنه يتعين عليهم البدء في شراء الكتب وأخذ الدورات لتعلم لغة جديدة.
يلاحظ مطورو النخبة أن هناك الكثير من العامة يستخدمون لغة البرمجة الحالية الخاصة بهم، ويبدأون في البحث عن شيء يميزهم بشكل أفضل عن زملائهم المتوسطين.
من يهتم بالتكنولوجيا التي تستخدمها، طالما أنها تعمل، وأنت ومستخدموك راضون عنها؟
هذا هو جمال الأشياء الجديدة: هناك دائمًا شيء جديد قادم. لا تدع السعي وراء الأشياء الجديدة اللامعة يصبح هدفك عن طريق الخطأ. تجنب أن تصبح مطورًا مغناطيسيًا. كن انتقائيًا في سعيك وراء الأشياء اللامعة والجديدة، وقد تجد نفسك مطورًا أفضل نتيجة لذلك.
أتمنى أن تكون مجرد دعابة.
يمكنك دائمًا السؤال هنا، قد يعرفون :ابتسامة:
لا، لماذا تقول ذلك؟
ربما لأن المتحمسين لـ Rust يستخدمون Discourse؟ أو ربما إذا كان النقل سيستغرق يومي عمل فقط لكانوا قد أنجزوه بالفعل، فقط من أجل الرياضة والمرح؟
أنا مذهول جدًا من هذا الموضوع لدرجة أنني لن أحتاج إلى دوائي اليومي 
Discourse آمن من ناحية الذاكرة. Ruby هي لغة آمنة من ناحية الذاكرة؛ جميع اللغات التي تجمع القمامة آمنة. الفرق الرئيسي مع Rust في هذا الصدد هو متى يتم إجراء فحوصات الأمان؛ تقوم Rust بها في وقت الترجمة، وتقوم Ruby بها في وقت التشغيل.
تتعامل Rust مع عدد قليل فقط من فئات الأخطاء، وبشكل أساسي تلك الناتجة عن افتقار C++ لجمع القمامة. بالتأكيد من الرائع أنهم وجدوا طريقة للقيام بذلك مع الحفاظ على فوائد الأداء النظرية الممكنة مع المؤشرات، لكن هذا لا يمنع بأي حال من الأحوال أنواع الأخطاء التي قد تراها كمستخدم. على سبيل المثال، إذا استخدمت < عندما كنت أقصد <=، وحصلت على خطأ “off-by-one” نتيجة لذلك، فلن تنقذني Rust. إذا نسيت تشغيل رسالة نجاح بعد اكتمال إجراء ما، فلن تنقذني Rust.
ما يمنع الأخطاء بالفعل هو نوع التطوير الموجه بالاختبارات الذي ينشره Discourse بالفعل. هناك عدد قليل جدًا من المشاريع التي يمكنك نشرها مباشرة من master وتتوقع أن تكون مستقرة، ولكن Discourse هو أحدها.
تظهر “المنصات الحديثة” في كل مكان باستخدام JavaScript للواجهة الخلفية والواجهة الأمامية. تحتل Ruby المرتبة الثانية خلف Rust في الشعبية (Kotlin بينهما)، لذا فهي ليست لغة نادرة في الوقت الحالي. بالتأكيد، قد تبدو الأمور مختلفة بعد 10 سنوات أخرى، ولكن حتى إعادة الكتابة إلى Rust ستكون ديونًا تقنية في غضون 10 سنوات.
من الصعب نقل مدى سذاجة هذا البيان، ولهذا السبب يضحك الجميع على الفكرة. لقد رأيت مطوري يعيدون هيكلة التعليمات البرمجية لمدة 3 سنوات حتى الآن، وهم على وشك البدء في الترحيل من wxWidgets/ShuttleGUI إلى Qt/QML - وهو، للسياق، انتقال من C++ إلى C++، فقط مجموعة أدوات واجهة مستخدم مختلفة. من الصعب فقط تحويل التعليمات البرمجية مع ضمان بقاء السلوك متطابقًا. 12-16 يومًا هو الوقت الذي ستحتاجه للتخطيط فقط قبل أن يبدأ أي شخص في العمل على الأرجح.
قد لا أكون المطور الأكثر إنتاجية، لكن استغرقت 3 أسابيع فقط لترحيل إضافة Poll إلى Glimmer Components (وهو ليس تغييرًا في اللغة حتى!)
لا أعرف عن Rust أو Ruby، لكنني أشعر أنه خلال العام الماضي، قام فريق CDCK بعمل رائع في إعادة كتابة الواجهة الأمامية باستخدام مكونات Ember 5 و Glimmer. لقد تزامن ذلك بالفعل مع إعادة بناء الواجهة الأمامية بمكونات وأنماط موحدة. أنا معجب بالجهد المنسق والغرض الذي تم وضعه وراء هذا 
لذلك، بالنسبة لي، اتخذوا قرارًا رائعًا بشأن ما يجب تحديثه لأنه أحدث فرقًا كبيرًا في الحفاظ على Discourse حديثًا وممتعًا للاستخدام!
مانويل، فيما يتعلق بالأنماط (CSS)، هل هذا موثق في أي مكان؟ ما الذي تعتبره التغييرات الرئيسية؟ هل تشعر أن بنية كود CSS في discourse أصبحت أسهل في التعامل معها الآن؟
فيما يتعلق بالأنماط، فإن التغييرات الرئيسية التي أراها هي:
بالنسبة لي، هذا يجعل تخصيص Discourse أسهل وأكثر دقة. لكنني أعتقد أن الأمر يعتمد على معرفتك العملية. يمكنني أن أتخيل أن هناك منحنى تعلم أكثر حدة الآن للأشخاص الذين يريدون فقط إجراء بعض التعديلات وليسوا على دراية كبيرة بـ CSS.
حول التوثيق، يمكنك الاطلاع على دليل الأنماط وأعتقد أن أسهل طريقة لمسح الخصائص المخصصة المتاحة هي استخدام أدوات المطور في متصفحك. Documentation يجري إعادة العمل عليه أيضًا. حاليًا، هناك قسمان في #documentation:developer-guides، Themes & Components و Interface. ولكن هناك نطاق واسع بين مجرد الرغبة في تعريف بعض الأنماط المخصصة وتأليف مكون. ربما يكون بعض هذا مدفونًا بعمق شديد بين مواضيع المطورين؟ 
إذا كنت ستقوم بنقله إلى لغة أخرى، أتوقع أن تكون لغة Go خيارًا أفضل. أحد المزايا التي أتوقع أن يقدرها مسؤولو الويب هو عدم الحاجة إلى إعادة البناء، حيث أنها تقوم بتوزيع ملفات ثنائية ثابتة. هذا يجعل الحاويات غير ضرورية إلى حد كبير أيضًا. في الواقع، إحدى الميزات التي تبدو مطلوبة بشدة مع Discourse هي القدرة على بناء التطبيق على جهاز مختلف عن خادم الويب الخاص بك. حاليًا، مع الحد الأدنى من خادم VPS الأرخص، يستغرق البناء ما يقرب من 10 دقائق. من المحتمل أن يكون هذا جزءًا بسيطًا من الوقت إذا تمكنت من البناء محليًا على محطة العمل الخاصة بي ثم شحن الملفات الثنائية النهائية إلى خادم الويب للتشغيل. ضع في اعتبارك أن لغات مثل Go تسمح لك بالترجمة المتقاطعة بسهولة، بحيث يمكنك البناء على جهاز Mac M1 الخاص بك ثم النشر على خادم ويب x86 (أو حتى مجرد البناء والشحن والنشر على ARM).
أعتقد حاليًا أن أكبر وقت مستغرق أثناء البناء هو تجميع الواجهة الأمامية، لذا فإن “الذهاب أو عدم الذهاب” أمر لا معنى له فيما يتعلق بوقت البناء.
لن يحل أي من Rust أو Go محل الواجهة الأمامية …
(ملاحظة: أنا أحب Go أيضًا … )