کدام زبان: Rust یا Go؟ نگاهی دوباره از دل تجربه‌ی واقعی
چند وقت پیش مطلبی نوشتم با عنوان «آینده‌ی Rust در مهندسی داده» و یک مطلب دیگر در خصوص مهاجرت بخشی از کدهای GO در دیسکورد به Rust. هنوز هم به آن حرف‌ها باور دارم:
بخش زیادی از ابزارهای آینده‌ی این حوزه یا با Rust بازنویسی می‌شوند یا به شکل native با آن توسعه می‌یابند — دلیلش هم مشخص است: سرعت بالا، کنترل دقیق حافظه، و ویژگی‌هایی مثل «zero-cost abstractions» (که شاید بشود در فارسی گفت «انتزاع‌های بدون سربار» یا ساده‌تر: «کد تمیز بدون هزینه‌ی پنهان عملکردی»).
اما حالا، بعد از چند ماه کار عملی با هر دو زبان — هم در پروژه‌های شخصی و هم از خلال مطالعه‌ی تجربه‌ی تیم‌های بزرگ دنیا — نگاهم کمی تغییر کرده. شاید بهتر بگویم: «واقع‌گرایانه‌تر» شده‌ام.
خلاصه اینکه برای من ، Rust مثل یک شمشیر سامورایی‌ست: تیز، زیبا، اما نه برای کارهای روزمره. در مقابل، Go شبیه یک آچار فرانسه‌ی صنعتی است. نه از آن ابزارهای خاص و نادر، اما محکم، ساده، و حاضر برای کارهای روزمره.
🎯 یکی از تجربه‌هایی که نگاه من را به‌کلی تغییر داد، بررسی موردی جالبی بود از تیمی که یک سرویس کلیدی را با سه زبان مختلف پیاده‌سازی کرد : Go، Rust، و Node.js. نه روی کاغذ، نه در بنچمارک‌های آزمایشگاهی، بلکه در میدان واقعی نبرد: یک اپلیکیشن واقعی، با بیش از یک میلیون کاربر و هدایت ترافیک زنده بین این سه سرویسی که با سه زبان مختلف هر کدام دقیقا یک کار مشابه را انجام می‌دادند. تجربه‌ای که در زیر نتایج آنرا با هم مرور می‌کنیم.
We Didn’t Benchmark It. We Went to War With It: Go vs Rust vs Node at 1M Users
When benchmarks meet reality, reality wins every time.
https://medium.com/@kanishks772/we-didnt-benchmark-it-we-went-to-war-with-it-go-vs-rust-vs-node-at-1m-users-60565cd59b1f
سرویسی که ساختند، شامل احراز هویت، پیام‌رسانی بلادرنگ، و آپلود فایل بود — چیزی شبیه به ستون فقرات یک اپلیکیشن پیام‌رسان. پیاده‌سازی اولیه با Node.js بود، اما دیگر جواب نمی‌داد: نشت حافظه، جهش‌های CPU، و زمان پاسخ‌هایی که باعث rage-quit کاربران می‌شد.
📚به‌جای فرضیه‌سازی، تیم دست‌به‌کار شد: همان سرویس را با Go و Rust هم نوشت و ترافیک را به‌طور مساوی بین هر سه تقسیم کرد. نتیجه چه شد؟
«Rust عملاً از نظر عملکرد، رقبا را پشت سر گذاشت.» اما آنچه این تیم یاد گرفت، چیزی بود که اغلب در بنچمارک‌ها دیده نمی‌شود:
عملکرد بالا، بدون بهره‌وری، کافی نیست.
⚠️توسعه با Rust 40٪ زمان بیشتری می‌برد. اشکال‌زدایی درگیر borrow checker می‌شد و اضافه‌کردن یک فیچر ساده، به جنگ با سیستم Typing منتهی می‌گردید.
✅در مقابل، Go سرعت توسعه‌ی بالایی داشت، کتابخانه استاندارد کافی و کاربردی، و راه‌اندازی ساده. هرچند کمی از Rust کندتر بود، اما برای تیم، توسعه با Go سه برابر سریع‌تر از Rust و دو برابر سریع‌تر از Node بود.
در نهایت، این تیم از هر سه زبان استفاده کرد:
🔹 Node.js برای ابزارهای مدیریتی و پروتوتایپ‌های سریع
🔹 #Go برای سرویس‌های اصلی و عمومی
🔹 #Rust برای بخش‌هایی که واقعاً performance-critical بودند
درس‌هایی از میدان نبرد
✅ واقعیت از بنچمارک قوی‌تر است. کدی که در تولید اجرا شود، تفاوت‌ها را نشان می‌دهد، نه کدهایی که فقط در محیط‌های تست اجرا شده‌اند.
✅ تجربه‌ی تیم از زبان مهم‌تر است. زبانی که تیم در آن مهارت دارد، اغلب از زبان بهتری که تیم با آن غریبه است، نتیجه‌ی بهتری می‌دهد.
✅ انتخاب تکنولوژی، مسابقه‌ی محبوبیت نیست. برنده، زبانی است که بهترین توازن بین بهره‌وری، عملکرد، و قابل نگهداری بودن را برای پروژه‌ی خاص شما ایجاد کند.
✅ چندزبانی بودن (polyglot) مزیت است، نه نقطه‌ضعف. گاهی بهترین راه این است که یک زبان را همه‌جا استفاده نکنیم. هر ابزار برای کاری ساخته شده.
💡 نتیجه‌گیری شخصی من
Rust هنوز آینده‌ی ابزارهای مهندسی داده است — مخصوصاً در سطح زیرساخت. اما در بسیاری از پروژه‌های کاربردی، از سرویس‌های داخلی گرفته تا microserviceهای API، Go انتخابی‌ست منطقی‌تر و واقع‌گرایانه‌تر.
ما همه مثل Discord نیستیم. منابع، مقیاس و اولویت‌های تیم‌ها متفاوت‌اند.
اما مهم‌تر از انتخاب بین Rust یا Go، این است که انتخاب‌مان با چشمان باز باشد — از دل تجربه، نه فقط از روی بنچمارک‌ها یا توییت‌های ترند شده.