Rust به زبان پیش‌فرض ابزارهای خط فرمان جدید تبدیل می‌شود

Rust در سال ۲۰۲۶ به گزینه پیش‌فرض ابزارهای خط فرمان جدید تبدیل شده است و به آرامی جای Go، Python و C را در دسته‌ای گرفته که Go از اواسط دهه ۲۰۱۰ بر آن تسلط داشت. Ripgrep، fd، bat، exa/eza، delta و ده‌ها ابزار CLI جدیدتر با Rust نوشته شده‌اند — و امروز هنگامی که تیمی یک پروژه CLI جدید آغاز می‌کند، Rust به‌طور فزاینده‌ای نخستین زبانی است که به آن توجه می‌شود، نه یک گزینه گوشه‌ای.

این داستان درباره چرخه‌های هایپ نیست. داستانی است درباره مجموعه‌ای خاص از مصالحه‌ها — تأخیر راه‌اندازی، ایمنی حافظه و توزیع تک‌باینری — که برای ابزارهای خط فرمان اهمیت فوق‌العاده‌ای دارند اما برای سرویس‌های وب که Go هنوز بر آن‌ها تسلط دارد، اهمیت بسیار کمتری دارند.

چرا ابزارهای CLI به‌طور خاص به Rust گرایش دارند

یک ابزار CLI هزاران بار در روز توسط یک توسعه‌دهنده فراخوانده می‌شود، اغلب در حلقه‌های تنگ (مثلاً: یک linter که با هر ذخیره فایل اجرا می‌شود، یا یک ابزار جستجو که از طریق یک shell script پایپ می‌شود). تأخیر راه‌اندازی در این فرکانس به شکلی انباشته می‌شود که برای یک سرور وب با اجرای طولانی چنین نیست. Rust به کد بومی بدون runtime یا garbage collector کامپایل می‌شود، بنابراین یک ابزار CLI ساخته‌شده با Rust در چند میلی‌ثانیه یک‌رقمی شروع به کار می‌کند — ابزارهای Go هم سریع شروع می‌کنند، اما هزینه کوچکی برای GC و مقداردهی اولیه runtime می‌پردازند که Rust نمی‌پردازد.

ایمنی حافظه بدون garbage collection عامل دوم است. ابزارهای CLI اغلب ورودی‌های ناامن را پردازش می‌کنند — مسیرهای فایل دلخواه، فایل‌های config ناقص، آرگومان‌های خط فرمان مخرب. مدل مالکیت Rust دسته‌های کاملی از باگ‌های حافظه را در زمان کامپایل شناسایی می‌کند، که برای ابزارهایی که بایت‌های خام از اینترنت دریافت می‌کنند اهمیت بیشتری دارد (مثلاً: یک formatter JSON که پاسخ‌های API را می‌پذیرد) تا برای، مثلاً، یک میکروسرویس داخلی با شکل ورودی مشخص.

باینری‌های تکی بر وابستگی‌های runtime برتری دارند

داستان توزیع عملی احتمالاً از داستان عملکرد مهم‌تر است. یک ابزار CLI ساخته‌شده با Rust به یک باینری استاتیک تنها با صفر وابستگی runtime کامپایل می‌شود — نه نسخه‌ای از مفسر Python که باید با آن تطابق داشت، نه Node.js که باید نصب شود، نه pip install که روی یک سیستم‌عامل دیگر خراب می‌شود. cargo install یا یک باینری دانلودشده فقط کار می‌کند. برای ابزارهایی که بین هزاران توسعه‌دهنده با محیط‌های ناهمگن توزیع می‌شوند، این امر یک دسته کامل از تیکت‌های پشتیبانی را حذف می‌کند.

ابزارهای Python، در مقابل، به‌طور معمول در محیط‌های Python ۳.۹ در برابر ۳.۱۱، تعارض وابستگی‌ها و سردرگمی محیط مجازی دچار مشکل می‌شوند — اصطکاکی که برای ابزاری که قرار است با یک brew install دو ثانیه‌ای کار کند، اهمیت فوق‌العاده‌ای دارد.

مصالحه منحنی یادگیری

هیچ‌کدام از این‌ها به معنای بی‌هزینه بودن Rust نیست. borrow checker منحنی یادگیری واقعی دارد و سرعت تکرار برای یک توسعه‌دهنده منفرد که یک ابزار سریع را نمونه‌سازی می‌کند، در Rust نسبت به Python یا حتی Go کندتر است، حداقل در ابتدا. تیم‌ها گزارش می‌دهند که یک ابزار CLI ساخته‌شده با Rust به‌طور محسوسی بیشتر طول می‌کشد تا به نسخه اول کارا برسد تا همان ابزار در Go — اما بار نگهداری با گذشت زمان معکوس می‌شود، چراکه Rust باگ‌هایی را در زمان کامپایل شناسایی می‌کند که Go و Python تنها در زمان اجرا آشکار می‌کردند، اغلب در ترمینال کاربر نه در یک مجموعه آزمون.

اکوسیستم نیز به اندازه کافی بالغ شده است که منحنی یادگیری نسبت به پنج سال پیش کمتر طاقت‌فرسا باشد. Crate‌هایی مانند clap (پارسینگ آرگومان)، serde (سریال‌سازی) و anyhow/thiserror (مدیریت خطا) اکنون همان زمینه‌ای را پوشش می‌دهند که در سال ۲۰۲۰ نیاز به boilerplate سفارشی داشت، به این معنا که یک توسعه‌دهنده Rust ماهر می‌تواند یک ابزار CLI با قابلیت‌های کامل را در یک بعدازظهر scaffold کند.

این موضوع برای تیم‌هایی که در حال انتخاب stack هستند چه معنایی دارد

اگر در حال ساخت یک ابزار CLI داخلی هستید که روزانه هزاران بار توسط سایر توسعه‌دهندگان اجرا می‌شود، مزایای تأخیر راه‌اندازی و تک‌باینری Rust اکنون به اندازه کافی بزرگ هستند که منحنی یادگیری اولیه تندتر را توجیه کنند — به‌ویژه از آن‌جا که crate‌هایی مانند clap و serde بیشتر شکاف بهره‌وری با Python را پر کرده‌اند. اگر ابزار شما یک اسکریپت یک‌بارمصرف است که چند بار اجرا می‌شود، یا اگر تیم شما هیچ تجربه‌ای با Rust ندارد و ضرب‌الاجل فشرده‌ای دارید، Python یا Go همچنان مسیر سریع‌تر از نظر عملی هستند — فقط به خاطر اینکه Rust مُد شده، کد را بازنویسی نکنید. و اگر در حال نگهداری یک ابزار CLI در Python هستید که از کاربرد خود پیشی گرفته است — راه‌اندازی کُند، زنجیره وابستگی شکننده، کاربرانی که از اصطکاک نصب شکایت دارند — این نشانه خاصی است که ارزش دارد به عنوان محرک بازنویسی با آن برخورد شود، نه ترجیح کلی زبان.