Rust يتحول إلى اللغة الافتراضية لأدوات سطر الأوامر الجديدة

أصبح Rust الخيار الافتراضي لأدوات سطر الأوامر الجديدة الصادرة في 2026، إذ يُزيح بهدوء Go وPython وC في فئة هيمن عليها Go منذ منتصف العقد الثاني من الألفية الثالثة. أدوات مثل Ripgrep وfd وbat وexa/eza وdelta، وعشرات أدوات CLI الأحدث، مكتوبة جميعها بـ Rust — وحين تبدأ فرقة مشروع CLI جديداً اليوم، بات Rust في الغالب أول لغة تُؤخذ بعين الاعتبار لا بديلاً محدود الانتشار.

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

لماذا تُفضّل أدوات CLI تحديداً Rust

تُستدعى أداة CLI آلاف المرات يومياً من طرف مطوّر واحد، في أحيان كثيرة ضمن حلقات متلاحقة (تخيّل: أداة linter تعمل عند كل حفظ لملف، أو أداة بحث تُمرَّر عبر سكريبت shell). يتراكم زمن الاستجابة عند الإطلاق بهذه الوتيرة بطريقة لا يُلقي إليها خادم الويب طويل الأمد بالاً. يُترجَم Rust إلى كود أصلي دون وقت تشغيل أو جامع نفايات، فتنطلق أداة CLI المكتوبة بـ Rust في أجزاء من المللي ثانية — تنطلق أدوات Go بسرعة هي الأخرى، لكنها تدفع ضريبة صغيرة لتهيئة GC ووقت التشغيل لا تعرفها Rust.

أمان الذاكرة دون جامع نفايات هو العامل الثاني. تعالج أدوات CLI في أغلب الأحيان مدخلات غير موثوقة — مسارات ملفات عشوائية، وملفات إعداد مشوّهة، وسيطات سطر أوامر معادية. يرصد نموذج ملكية Rust فئات بأكملها من أخطاء الذاكرة في وقت التصريف، وهو ما يكتسب أهمية أكبر للأدوات التي تستقبل بايتات خام من الإنترنت (تخيّل: منسّق JSON يقبل استجابات API) مقارنةً بـ microservice داخلي ذي شكل مدخلات معروف.

الملفات الثنائية المفردة تتفوق على تبعيات وقت التشغيل

قصة التوزيع العملي يمكن القول إنها أهم من قصة الأداء. تُصرَّف أداة CLI المكتوبة بـ Rust إلى ملف ثنائي ساكن واحد دون أي تبعيات لوقت التشغيل — لا إصدار مترجم Python يجب مطابقته، ولا Node.js لتثبيته، ولا pip install قد ينهار على نظام تشغيل مختلف. تعمل cargo install أو الملف الثنائي المُنزَّل مباشرةً دون أي متاعب. بالنسبة للأدوات الموزَّعة على آلاف المطوّرين في بيئات متباينة، يُلغي هذا فئة كاملة من تذاكر الدعم الفني.

أدوات Python، في المقابل، تتعطّل باستمرار عبر بيئات Python 3.9 مقابل 3.11، وتعارضات التبعيات، وارتباك البيئات الافتراضية — احتكاك جوهري لأداة يُفترض أن تكون على بُعد brew install واحد من العمل.

مقايضة منحنى التعلّم

لا يعني شيء من هذا أن Rust بلا تكلفة. لمدقق الاستعارة (borrow checker) منحنى تعلّم حقيقي، وسرعة التكرار لمطوّر منفرد يبني نموذجاً أولياً لأداة سريعة أبطأ في Rust منها في Python أو حتى Go، على الأقل في البداية. تُفيد الفرق بأن أداة CLI مكتوبة بـ Rust تستغرق وقتاً أطول ملحوظاً للوصول إلى نسخة أولى تعمل مقارنةً بالأداة ذاتها في Go — لكن عبء الصيانة ينعكس مع الوقت، إذ ترصد Rust الأخطاء في وقت التصريف التي لن تظهر في Go وPython إلا في وقت التشغيل، في أغلب الأحيان في طرفية المستخدم لا في مجموعة الاختبارات.

نضج النظام البيئي أيضاً بما يكفي لجعل منحنى التعلّم أقل قسوة مما كان عليه قبل خمس سنوات. حزم مثل clap (لتحليل الوسيطات) وserde (للتسلسل) وanyhow/thiserror (لمعالجة الأخطاء) تغطي اليوم المساحة ذاتها التي كانت تتطلّب كوداً نمطياً مخصصاً في 2020، ما يعني أن مطوّر Rust المتمكّن يستطيع بناء هيكل أداة CLI متكاملة المزايا في غضون بضع ساعات.

ما يعنيه هذا للفرق التي تختار مكدّسها التقني

إن كنت تبني أداة CLI داخلية ستُشغَّل آلاف المرات يومياً من قِبَل مطوّرين آخرين، فإن مزايا Rust في زمن الإطلاق والملف الثنائي المفرد باتت كبيرة بما يكفي لتبرير منحنى التعلّم الأكثر حدةً في البداية — لا سيما أن حزماً مثل clap وserde قد سدّت معظم فجوة الإنتاجية مع Python. أما إن كانت أداتك سكريبتاً منفرداً يُشغَّل حفنة من المرات، أو كان فريقك خالياً من أي خبرة في Rust ولديه موعد نهائي ضيق، فلا يزال Python وGo المسار الأسرع عملياً — لا تُعِد الكتابة بـ Rust لمجرد أنها رائجة. وإن كنت تصون بالفعل أداة CLI مكتوبة بـ Python تجاوزت حالة استخدامها — بطء في الإطلاق، وسلسلة تبعيات هشّة، ومستخدمون يشكون من صعوبة التثبيت — فتلك الإشارة تحديداً هي المبرر للإعادة الكتابة، لا التفضيل العام للغة.