aech
Link
click to show
click to show
بازنویسی Bun از Zig به Rust؛ کاملاً با هوش مصنوعی
همونطور که احتمالاً میدونید، Bun یک JavaScript Runtime مدرنه که با تمرکز روی سرعت ساخته شده. این پروژه در ابتدا با Zig توسعه پیدا کرد؛ چون Zig به یک تیم کوچک اجازه میداد بدون سربار Garbage Collector و Runtimeهای سنگین، خیلی سریع یک Runtime پرسرعت بسازه. دسترسی مستقیم به حافظه، سادگی زبان و تعامل خوب با C باعث شد معماری و طراحی سطح پایین Bun حول Zig شکل بگیره؛ موضوعی که Jarred Sumner، خالق Bun، هم بارها بهش اشاره کرده.
اما در ماه می امسال، تیم Bun اعلام کرد که قصد داره کل پروژه رو به Rust مهاجرت بده. حالا این بازنویسی انجام شده و کدهای Rust هم وارد شاخه اصلی پروژه شدن. نکتهی عجیب اینجاست که تقریباً تمام این کدها توسط Claude Code تولید شدن و علاوه بر بازنویسی، تعدادی از باگهای قدیمی هم در همین فرآیند برطرف شدن.
آیا مشکل از Zig بود؟
از نگاه تیم Bun، مشکل اصلی خود Zig نبود؛ بلکه مدیریت دستی حافظه در کنار Garbage Collector جاوااسکریپت بود. این ترکیب باعث نشت حافظه، کرش و هزینهی بالای نگهداری کد میشد و با بزرگتر شدن پروژه، اتکا به دقت برنامهنویس دیگر کافی نبود.
با این حال، جرد تأکید میکنه که Zig نقش مهمی در موفقیت اولیه Bun داشته و بخش بزرگی از معماری و عملکرد فعلی پروژه مدیون همون انتخاب اولیه است.
در مقابل، اندرو کلی، خالق Zig، بارها گفته مشکل از زبان Zig نبوده، بلکه از نحوهی استفادهی Bun از اون بوده. حتی جایی گفته بود داخل تیم Zig، از Bun بهعنوان مثالی استفاده میکنیم که «چطور نباید با Zig برنامه نوشت».
چرا Rust؟
بخش بزرگی از باگهای Bun به مدیریت حافظه مربوط میشد. در Rust این دسته از خطاها معمولاً هنگام کامپایل شناسایی میشن و مکانیزم Ownership و Drop هم آزادسازی حافظه رو مدیریت میکنن. در نتیجه، به جای اینکه توسعهدهنده همیشه مراقب همهچیز باشه، کامپایلر جلوی بخش زیادی از اشتباهات رو میگیره.
البته بازنویسی پروژهای با بیش از ۵۳۵ هزار خط کد Zig اصلاً تصمیم سادهای نبود. انجام دستی این کار حداقل یک سال زمان میبرد و عملاً توسعهی Bun رو متوقف میکرد. تیم ابتدا سعی کرد با Smart Pointerهای الهامگرفته از Rust و سختگیرتر کردن قوانین کدنویسی، مشکلات رو داخل Zig حل کنه، اما در نهایت تصمیم گرفت از Claude Code برای بازنویسی کامل پروژه استفاده کنه.
کلاد چطور این بازنویسی را انجام داد؟
جرد میگه ماجرا به سادگی این نبود که به Claude بگه «کل Bun رو به Rust تبدیل کن». قبل از شروع، ساعتها صرف طراحی Workflowها و استراتژی بازنویسی شد.
در نهایت، حدود ۵۰ Workflow مختلف به مدت ۱۱ روز تقریباً بدون توقف اجرا شدن؛ با هزینهای نزدیک به ۱۶۵ هزار دلار.
هر Workflow وظیفهی مشخصی داشت؛ از تبدیل الگوهای Zig به Rust و رفع خطاهای کامپایل گرفته تا اجرای bun test و bun build. پاس کردن تستها و در نهایت Refactor کد.
جرد هم بهجای اصلاح مستقیم خروجیها، Workflowها و Promptها رو بهبود میداد تا هر بار کیفیت خروجی بهتر بشه.
برای اعتماد به بیش از یک میلیون خط کد تولیدشده توسط هوش مصنوعی هم از روشی شبیه Code Review واقعی استفاده شد. یک Claude کد رو مینوشت و چند Claude دیگه، در Contextهای جداگانه، فقط وظیفه داشتن ایرادها و باگها رو پیدا کنن. نویسندهی کد Reviewer نبود و Reviewer هم اجازهی تغییر کد رو نداشت.
بعد از تبدیل همهی فایلها، مرحلهی اصلی یعنی رفع خطاها و پاس کردن تستها شروع شد. این چرخه بارها تکرار شد تا در نهایت تمام تستهای Bun روی همهی پلتفرمها با موفقیت پاس شدن و کد وارد شاخهی اصلی پروژه شد.
آیا این بازنویسی موفق خواهد بود؟
در کوتاهمدت احتمالاً بله. تستها مسیرهای اصلی رو پوشش میدن، نسخههای Canary مشکلات واضح رو پیدا میکنن و Rust هم بخش بزرگی از خطاهای مدیریت حافظه رو حذف میکنه.
اما سؤال اصلی بلندمدته.
اگر چند ماه بعد یک باگ پیچیدهی Concurrency یا یک حالت مرزی عجیب ظاهر بشه، مهندسی که مسئول دیباگ کردنشه با کدی روبهرو میشه که تقریباً هیچ انسانی اون رو بهطور کامل ننوشته یا خطبهخط درکش نکرده.
در نهایت، شرطبندی اصلی این پروژه نه روی Zig و Rust، بلکه روی این سؤاله که آیا یک Codebase عظیم که عمدتاً توسط هوش مصنوعی تولید شده، در بلندمدت هم قابل نگهداری و قابل اعتماد خواهد بود یا نه.
از طرف دیگه، بعضیها هم معتقدن این اتفاق فقط یک بازنویسی فنی نبوده و بخشی از یک کمپین بازاریابی برای Claude محسوب میشه.
پاسخ اینکه این تصمیم در نهایت موفق خواهد بود یا نه، فعلاً مشخص نیست؛ چیزی که فقط با گذر زمان معلوم میشه.
مقاله ای که خود جرد منتشر کرده و در مورد این تغییرات توضیح داده:
https://bun.com/blog/bun-in-rust
#News
@Syntax_fa
13 · 1.3K ·