مراجعة لغة البرمجة Rust: هل تستحق التعلّم؟

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

في هذا التناقض يكمن السؤال الحقيقي «هل تستحق Rust التعلّم»، ولهذا فإن «نعم» المطلقة لا تفيدك بشيء. Rust لغة مُصرَّفة تفرض مجموعتها الآمنة قواعد سلامة الذاكرة وقت الترجمة، دون الحاجة إلى جامع نفايات (garbage collector) وقت التشغيل.

لذا سألتزم بإجابة واضحة، وأسمّي الشرط الذي تتوقف عليه، وأريك كم يكلّف هذا الشرط.

النسخة المختصرة

تستحق Rust التعلّم إذا كنت تبني شيئًا طويل العمر يستحق فيه أن تدفع ثمن اكتشاف المترجم لفئة كاملة من الأخطاء. وهي خيار خاطئ إذا كنت تحتاج إلى إطلاق تطبيق CRUD هذا الشهر، أو كنت تتعلّم البرمجة، أو تعدّ إعلانات الوظائف. 4 من 5، مع خصم لما تكلّفه قبل أن تؤتي ثمارها.

• ما الذي تشتريه: في Rust الآمنة، تحوّل قواعد الملكية والاستعارة أخطاء الاستخدام بعد التحرير (use-after-free) والتحرير المزدوج (double-free) والمراجع غير الصالحة وسباقات البيانات إلى أخطاء وقت الترجمة بدلًا من حوادث في بيئة الإنتاج. هذه هي الفكرة كلها، وهي فكرة جيدة.
• ما الذي تدفعه: يجبرك المترجم على أن تكتب صراحةً قرارات الذاكرة التي تتخذها لغتك الحالية بصمت، وفي البداية يبدو ذلك وكأن الأداة تتعنّت.
• مسألة الاستمرارية محسومة. أنهى مشرفو النواة تجربة Rust في قمة المشرفين (Maintainers Summit) في ديسمبر 2025، وأُزيلت صفة «تجريبية» في Linux 7.0.
• مسألة الرواج ليست محسومة، وهي سؤال مختلف. تحتل Rust المركز #10 في مؤشر TIOBE لشهر سبتمبر 2026، صعودًا من #18 قبل عام.
• احتاجت خدمة Rust التي اختبرتها إلى ذاكرة للترجمة أكثر بكثير مما احتاجته للتشغيل: بلغت الذروة نحو 1 GB أثناء البناء، واستقرت عند نحو 3.5 MB أثناء التشغيل في وضع الخمول.
• مناسبة لك إذا كنت تطلق منتجات بلغة أخرى بالفعل وتبني شيئًا يكون فيه خطأ الذاكرة مكلفًا، أو كنت تعمل قرب برمجيات الأنظمة. غير مناسبة لك إذا كنت مقيّدًا بموعد نهائي، أو تبدأ من الصفر، أو تبحث عن اللغة ذات أكبر عدد من الوظائف الشاغرة.

كيف أُعدّت هذه المراجعة: أرقام البناء والتشغيل هنا من قياسي أنا. ثبّتُّ Rust 1.98.1، وكتبت خدمة ويب صغيرة بـ Axum، وقست ما احتاجته للترجمة وما احتاجته للتشغيل. جرى ذلك في حاوية معزولة (sandbox)، لا على عتاد مخصص، وهو مشروع واحد، فاعتبر الأرقام نقطة بيانات لا قانونًا. كل ما عدا ذلك مأخوذ من مصادر أولية أو موثوقة: رقعة النواة وتغطية LWN لها، ومنشورات Google الأمنية عن Android، ومؤشر TIOBE نفسه (مع تعليق أبريل عبر ما سجّله Slashdot منه)، وPhoronix عن نافذة الدمج في Linux 7.0، وسجلات CVE الخاصة بنواة Linux لثغرة Binder، وبيان Canonical نفسها، واستطلاع Stack Overflow لعام 2025. قرأت رقعة النواة. لم أدقق شيفرة Rust في النواة. ولست ممن يكتبون Rust منذ سنوات، لذلك حين تحكم هذه المراجعة على اللغة نفسها، فهي تعتمد على ممارسين يكتبونها منذ سنوات، وتذكر أسماءهم.

ما الذي يشتريه لك المترجم

أعطِ خيطَين (threads) مرجعًا قابلًا للتعديل إلى المتجه نفسه في Rust ولن تُترجَم الشيفرة. ليس تحذيرًا. وليس تنبيه lint يمكنك إسكاته تحت ضغط موعد نهائي. لن تُبنى ببساطة. هذا الرفض هو ما تشتريه في Rust الآمنة: تُدفع أخطاء الاستخدام بعد التحرير والتحرير المزدوج والمراجع غير الصالحة وسباقات البيانات إلى أخطاء ترجمة بدلًا من حوادث في الإنتاج. منفذ الهروب في Rust (unsafe) يمكنه تجاوز بعض هذه الضمانات، لذا فهذا ليس وعدًا مطلقًا بشأن كل قاعدة شيفرة مكتوبة بـ Rust.

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

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

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

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

هل لا تزال Rust تجريبية، أم أصبحت بنية تحتية للإنتاج؟

توقفت عن كونها تجريبية في ديسمبر 2025، ومن أنهى ذلك هم مشرفو النواة أنفسهم. في قمة المشرفين لعام 2025 خلصوا إلى أن Rust أثبتت جدارتها في النواة، تقنيًا واجتماعيًا. نقل Jonathan Corbet من LWN هذا الإجماع في 10 ديسمبر 2025: Rust في النواة لم تعد تجريبية.

دخلت Rust إلى Linux الرئيسية في الإصدار v6.1 عام 2022 تحديدًا لإجراء تلك التجربة. جاءت رقعة Miguel Ojeda التي تزيل الصفة بعد القمة بثلاثة أيام، ودخلت ضمن نافذة الدمج في Linux 7.0.

«لكن التجربة انتهت، أي أن Rust باقية.»

Miguel Ojeda، «rust: conclude the Rust experiment»، LKML، 13 ديسمبر 2025

وبشكل منفصل، وقبل ذلك: إعادة كتابة Google بلغة Rust لمشغّل Binder في Android، وهو طبقة IPC التي تتواصل عبرها عمليات Android (باستمرار)، دُمجت في Linux 6.18، الذي صدر في 30 نوفمبر 2025. افصل هذا الإنجاز عن إجماع القمة. فهو اللحظة التي راهنت فيها شركة بمنتج قائم على Rust في النواة، لا مجموعة مشرفين تبارك الفكرة. ومنذ ذلك الحين أنتجت Rust في النواة أول ثغرة CVE لها: CVE-2025-68260، وهي حالة تسابق (race condition) في مشغّل Binder نفسه أعلنها Greg Kroah-Hartman في 16 ديسمبر 2025، ظهرت في 6.18 وأُصلحت في 6.18.1. ركّزت التقارير الأولى على الأعطال، لكن التقييم اللاحق من فريق CVE في نواة Linux يمنح CVE-2025-68260 درجة 7.8 (عالية) ويصف مسارًا محليًا لتصعيد الصلاحيات عبر إفساد ذاكرة النواة. كما أن المشغّل نفسه (rust_binder) تراكمت عليه ثغرات CVE إضافية منذ ذلك الحين.

في Android تصبح الأدلة رقمية. ذكرت مدونة Google الأمنية في ديسمبر 2022 أنه لم تُكتشف أي ثغرة واحدة في سلامة الذاكرة في شيفرة Rust الخاصة بـ Android، مقابل نحو 1.5 مليون سطر من Rust في AOSP ونحو 21% من كل الشيفرة الأصلية (native) الجديدة في Android 13. هذا تصريح من 2022 بنطاق 2022. أما منشورات Google اللاحقة فتعطي الاتجاه الأطول: شكّلت مشكلات سلامة الذاكرة 76% من ثغرات Android في 2019 و24% في 2024، مع انخفاض العدد الخام من أكثر من 220 إلى 36 متوقعة. هذه الأرقام لا تعني شيئًا إلا مقارنةً بخط الأساس الذي حلّت محله، وهو C وC++ كتبها مهندسون ممتازون بأدوات ممتازة.

إشارتان أصغر تشيران إلى الاتجاه نفسه. مشغّل رسوميات Apple AGX في Asahi Linux مكتوب بـ Rust، وقد كتبه مشروع Asahi Linux عبر الهندسة العكسية وليس Apple. تحديث rust-coreutils من Canonical يقول إن Ubuntu 26.04 LTS يأتي مع rust-coreutils 0.8.0 لمعظم الأدوات. وتبقى ثلاث أدوات على GNU coreutils (cp, mv, rm) لأن ثماني مشكلات TOCTOU كانت لا تزال مفتوحة في 22 أبريل 2026؛ وتستهدف Canonical الإصدار 26.10 لبقية الأدوات.

هذا هو المحور الذي أمنحه أعلى درجة، والسبب هو نوع الالتزام المعني. مشرفو النواة لا يتراجعون عن إنهاء التجارب، وGoogle لا تتراجع عن إعادة كتابة بهذا الحجم، وCanonical لا تضع coreutils مُعادة الكتابة في إصدار LTS لترى كيف ستسير الأمور. مهما حدث لشعبية Rust، على أحدٍ ما أن يصون تلك الشيفرة لسنوات.

هل ماتت Rust، أم أنها تستقر فحسب؟

لا. عادلت Rust أفضل مركز لها على الإطلاق في TIOBE، وهو #13، في يناير 2026. وبعد ثلاثة أشهر تراجعت إلى #16، وكتب الرئيس التنفيذي لـ TIOBE، Paul Jansen، في أبريل 2026، في تعليق نقله Slashdot حينها، أن نمو شعبية Rust «يبدو أنه يستقر» وأن الوصول إلى مركز ضمن أفضل 10 «يبدو الآن أبعد من ذي قبل».

كان يصف بلوغ Rust أعلى مركز لها على الإطلاق في مؤشره، وهو مركز احتلته أول مرة في يوليو 2024، ثم تخلّيها عنه.

مؤشر TIOBE لشهر سبتمبر 2026 يضع Rust في المركز #10، صعودًا من #18 قبل عام، متجاوزةً المركز #13 الذي وصفه TIOBE بأنه أعلى مركز لها على الإطلاق في يناير.

قراءتي: الاستقرار كان حقيقيًا. كان مطبًّا هوائيًا، لا سقفًا. وهذا أفضل من رواية أي من المعسكرين، لأن «Rust توقفت» صار خاطئًا الآن، و«Rust لا تفعل إلا الصعود» لم يكن صحيحًا قط.

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

الإشارة الأقوى على المزاج العام هي استطلاع Stack Overflow، حيث Rust مرة أخرى اللغة الأكثر إعجابًا بين لغات البرمجة في 2025 بنسبة 72%: أي الأشخاص الذين استخدموها في العام الماضي ويريدون الاستمرار في استخدامها. هذه نية استمرار في الاستخدام، لا تبنٍّ، وهي هنا إشارة أنفع من الشعبية الخام إن كنت تقرر هل ستستمتع بالبقاء مع اللغة.

الزخم غامض، وأعطيه وزنًا أقل من الاستمرارية المذكورة أعلاه، لأنك لا تستثمر في تصنيف.

كم يكلّفك تعلّم Rust

تأتي التكلفة مبكرًا ودفعة واحدة. الشيفرة التي كانت Python أو Java أو C# ستشغّلها بسرور تُرفض، مرارًا، لأسباب تبدو اعتباطية حتى يستقر نموذج الملكية في ذهنك، ولا سبيل لتأجيل ذلك. لا يمكنك تجاوز مدقق الاستعارة (borrow checker) بمواصلة الإطلاق كما يمكنك مواصلة الإطلاق دون فهم كامل لأداة ORM التي تستخدمها.

هذا هو الجزء الذي فاجأني، وهو يسير عكس ما تتوقعه. في سلسلة r/rust بعنوان «Struggling to learn Rust»، الرد الذي حظي بأكبر تفاعل يعيد صياغة المشكلة على أنها عدم ألفة لا صعوبة، وتشير السلسلة إلى أن المطورين المتمرسين القادمين من لغات تعتمد على جامع النفايات هم من يواجهون وقتًا أصعب. يقولها u/Voxelman بوضوح: «Rust ليست صعبة. إنها مختلفة.» وفي السلسلة نفسها يصف طريقه إليها: C64 Basic، ثم مجموعة من اللغات الأمرية، ثم أول احتكاك مع Rust «كان أي شيء إلا مبهرًا» لأن التخلص من العادات القديمة استغرق وقتًا.

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

ويظهر نمط آخر مرارًا في تلك السلسلة، وهو يحوّل خطأً في الترتيب إلى مشكلة ثقة: يعلق الناس لا في Rust بل في اختيار إطار عمل للويب، محاولين تعلّم اللغة عبر Axum أو Actix قبل أن يستقر مفهوم الملكية. وكما قال u/jmartin2683، هذا «مثل محاولة تعلّم ruby عبر تعلّم rails.»

أرى أن معظم التحذيرات بشأن التكلفة تشير إلى الشيء الخطأ. خصّص ممارسة متواصلة، لا عطلة نهاية أسبوع، ولا تعتبر الإحباط المبكر حكمًا على قدرتك.

تحتاج Rust إلى جهاز أكبر للبناء منه للتشغيل

هذه هي النتيجة التي لم أتوقعها: بناء مشروع Rust هذا استهلك ذاكرة أكثر من تشغيله بأضعاف مضاعفة. بنيت خدمة Axum صغيرة (Tokio بمجموعة الميزات full وserde وserde_json وtower، ومسار JSON واحد، ونحو 60 crate في شجرة الاعتماديات) باستخدام rustc وcargo 1.98.1، مع strip = true في ملف تعريف الإصدار (release profile)، ثم بنيتها من الصفر مرتين:

# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --release

مع تحديد مهمة ترجمة واحدة فقط (--jobs 1)، جاءت ذروة الذاكرة عبر cargo وrustc والرابط (linker) بين 464 MB و527 MB بحسب أي طريقتَي القياس اللتين استخدمتهما تأخذ (قستها بطريقتين لأن الرقم الأول بدا نظيفًا أكثر من اللازم)، واستغرق البناء 113 ثانية. ومع التوازي الافتراضي على أربع وحدات vCPU، تضاعفت ذروة الذاكرة تقريبًا إلى نحو 1 GB وانتهى البناء في نحو 35 ثانية. المتغيّر هنا هو التوازي، لا المشروع. مهام أكثر تعني عمليات rustc أكثر مقيمة في الذاكرة في الوقت نفسه، ولهذا فالمترجمات من أعباء العمل القليلة التي تأخذ بسرور كل نواة تعطيها إياها لدقائق متواصلة.

حجم البرنامج النهائي 1.3 MB بعد التجريد (stripped)، ويستقر في الخمول عند نحو 3.3 إلى 3.6 MB من الذاكرة المستخدمة.

مع التوازي الافتراضي، هذه ذاكرة للترجمة أكثر بمئتين إلى ثلاثمئة ضعف مما يلزم للتشغيل؛ ومع تحديد مهمة واحدة تبقى أكثر من مئة ضعف بكثير. إن حددت حجم خادم على قدر ما تحتاجه خدمة Rust في الإنتاج، فقد ينتهي بك الأمر بجهاز لا يستطيع بناءها، ونمط الفشل ليس خطأً واضحًا: بل قاتل نفاد الذاكرة (OOM killer) يُسقط rustc في منتصف البناء، أو مترجم يُنهك ذاكرة التبديل (swap) لعشرين دقيقة. هناك حلّان ينجحان. ابنِ في مكان فيه متسع وانقل الملف التنفيذي، وهو النمط نفسه في إبقاء جهاز بناء منفصل لأعمال Docker الثقيلة. أو ابنِ على الجهاز نفسه وامنحه مساحة: لخدمة بهذا الشكل، تكفي بارتياح بضعة غيغابايتات من RAM ووحدتا vCPU. وإن لم يكن ذلك متاحًا، فمنفذ الهروب هو --jobs 1 (نعم، إنه أبطأ؛ هذه هي المقايضة).

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

مشروع واحد، شكل واحد، جهاز واحد. كان الجهاز حاوية معزولة مشتركة، لا خادمًا مخصصًا، مع نحو 2 GB من الذاكرة المتاحة، لذلك كانت الذروة غير المقيّدة أقرب إلى سقفها مما ستكون عليه على جهاز أكبر. هذه ليست ثوابت عامة: إن كانت شجرة اعتمادياتك أكبر بأربع مرات أو كان ملف تعريف الإصدار لديك يفعّل التحسين وقت الربط (link-time optimization)، فتوقع أرقامًا مختلفة. شجرات الاعتماديات الأكبر، والتحسين وقت الربط، والشيفرة الكثيفة بالأنواع العامة (generics) قد ترفع ذاكرة البناء أكثر، لذا لا تعامل قياساتي كسقف عام.

أصنّف هذا تحت طريقة عملك، لا تحت ما إذا كنت ستتعلم اللغة. اعرفه قبل أن تصطدم به.

من يجب أن يتعلم Rust

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

تطلق منتجات بلغة أخرى بالفعل وتبني شيئًا طويل العمر يكون فيه خطأ الذاكرة مكلفًا. خدمة يجب أن تبقى تعمل. مكتبة تعتمد عليها فرق أخرى. أي شيء يعني فيه خطأ use-after-free مراجعةً لحادث، لا مجرد تتبع مكدس (stack trace) في طرفيتك. هذه هي الحالة التي بُنيت الضمانة كلها لأجلها، وما تدفعه مقدمًا يُستهلك على امتداد عمر الشيء الذي تبنيه.

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

تريد الأثر الجانبي. معلّقان في سلسلة r/rust تلك يختلفان تمامًا حول قيمة Rust المهنية، ويصلان إلى النتيجة نفسها هنا. u/tyler_church، الذي يقول إنها لم تؤثر إطلاقًا في مسيرته المهنية، يقرّ مع ذلك بـ«ربما تأثيرات خفية على طريقة كتابتي لبرامج أخرى بلغات أخرى». u/SirKastic23، الذي يتقاضى أجرًا لكتابة Rust منذ عامين، يقول إنها وسّعت مهاراته البرمجية بطرق لم يتوقعها قط. شخصان، لا دراسة، لكنها الفائدة التي تبقى حتى لو لم تكتب Rust احترافيًا أبدًا: تغيير في طريقة تفكيرك، لا سطر في سيرتك الذاتية.

من لا يجب أن يتعلم Rust

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

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

تتعلم البرمجة من الأساس. هذه النقطة تقسم فعلًا من يكتبون Rust لكسب عيشهم، والخلاف في سلاسل r/rust يسير في الاتجاهين، لذا موقفي أن إعطاء مبتدئ رمية عملة نصيحة سيئة أيًّا كان الوجه الذي تسقط عليه. تعلّم كيف تعمل الآلة في مكان أكثر تسامحًا أولًا، ثم عُد ودع المترجم يشدّ ذلك.

تختار لغة بحسب عدد إعلانات الوظائف التي تذكرها. لن أعطيك رقمًا هنا، لأنني لم أجد رقمًا للرواتب أو الوظائف الشاغرة في Rust يعود إلى مصدر أستطيع الدفاع عنه. ما يصفه u/crusoe في سلسلة r/rust تلك هو سوق بوظائف أقل وأكثر تخصصًا. هذا معلّق واحد في سلسلة واحدة، لا بيانات عن سوق العمل، لذا لن أحوّله إلى ادعاء بأن وظائف Rust نادرة عمومًا. إن كان حجم الوظائف هو عاملك الحاسم، فافحص الإعلانات الحالية في سوقك المستهدف قبل اختيار اللغة.

الأسئلة الشائعة

هل Rust مجانية؟

نعم. اللغة ومشاريعها الرسمية مرخّصة عمومًا بترخيص مزدوج بموجب ترخيص MIT وApache License 2.0، وتُثبَّت سلسلة الأدوات مجانًا عبر rustup. لا توجد فئة مدفوعة ولا ترخيص تجاري للشراء.

كم من الوقت يستغرق تعلّم Rust؟

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

هل Rust لغة برمجة أولى جيدة؟

جوابي لا، لكن يجب أن تعرف أن السؤال محل خلاف بين الممارسين المتمرسين. في سلسلة r/rust بعنوان «Struggling to learn Rust»، u/cassepipe يقول صراحةً إن Rust «ليست لغة أولى جيدة» بعد أن ارتدّ عنها ثم عاد إليها عبر C وC++، بينما u/Voxelman يجادل بالعكس: اللغات الأمرية مكان سيئ للبدء لأنها تعلّم عادات عليك التخلص منها لاحقًا. والخلاف نفسه يمتد لأربع صفحات في منتدى مستخدمي Rust الرسمي. لا توجد إجابة مجتمعية محسومة يمكن نقلها.

هل تحل Rust محل C++؟

لا. تُضاف Rust إلى جانب C وC++ وتُختار لمكونات جديدة محددة، وهذا شيء مختلف. في نواة Linux، تُضاف Rust إلى جانب قاعدة شيفرة C الحالية بدلًا من استبدالها بالكامل. وفي Android، كان النهج المعلن لـ Google هو كتابة الشيفرة الجديدة بلغات آمنة للذاكرة بدلًا من تحويل شيفرة C وC++ الحالية. توقع تعايشًا لوقت طويل.

هل Rust أسرع من Go؟

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