أكمل مشروع Bun نقلًا كبيرًا من Zig إلى Rust في مايو 2026، مع إجراء أكثر من مليون سطر من التغييرات في الكود و6778 عملية دفع خلال 11 يومًا. تم استخدام 64 نموذجًا من Claude للعمل بالتوازي، بتكاليف واجهة برمجة التطبيقات تبلغ 165 ألف دولار أمريكي. بعد النقل، تم حل مشكلات تسرب الذاكرة بشكل جذري، حيث انخفض استخدام الذاكرة من 6.7 جيجابايت إلى 609 ميجابايت بعد 2000 عملية بناء، مع تحسين الأداء بنسبة 2٪ إلى 5٪ وتخفيض حجم الملف الثنائي بنسبة حوالي 20٪. ومع ذلك، يحتوي الكود على حوالي 13000 كلمة مفتاحية "unsafe"، أي 178 ضعف مثيلاتها في المشاريع المماثلة، مع وجود 19 مشكلة رجعية معروفة، ولا يمكن مراجعة مليون سطر من التغييرات يدويًا من قبل البشر. حاليًا، تم شراء Bun من قبل Anthropic.

كاتب المقال، المصدر: InfoQ

في مايو 2026، أكمل مشروع Bun نقلًا واسع النطاق للرمز يكاد يكون نادرًا في تاريخ تطوير البرمجيات.

استغرقت هذه الهجرة من 3 مايو حتى الدمج الرسمي في الفرع الرئيسي في 14 مايو، أي 11 أيام فقط. استغرق كتابة الكود 6 أيام، وكان العملية بأكملها علنية. لكن جاريد سومنر استغرق تقريبًا شهرًا لكتابة مدونته الختامية، وهو أطول بكثير من وقت كتابة الكود.

كان هذا وقت التشغيل JavaScript يحتوي أصلاً على 535,496 سطرًا من كود Zig، دون تضمين التعليقات؛ كما أن حوالي 20% من الكود مكتوب بلغة C++، مع تضمين العديد من مكتبات C/C++. تم إعادة كتابته بالكامل باستخدام Rust بمساعدة الذكاء الاصطناعي، وشملت هذه العملية أكثر من مليون سطر من التغييرات، و6778 عملية دفع، وتشغيل حوالي 50 سير عمل ديناميكيًا عبر Claude Code.

وفقًا للبيانات التي كشف عنها سومنر، استهلكت هذه إعادة الكتابة 5.9 مليار رمز إدخال غير مخزن مؤقتًا، و690 مليون رمز إخراج، و72 مليار قراءة رمز إدخال مخزن مؤقتًا، بتكاليف تقدر بحوالي 165,000 دولار أمريكي وفقًا لأسعار API.

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

بعد هذا الإعادة الكتابية، سيصبح Bun v1.3.14 هو آخر إصدار مبني على Zig، وسيصبح Bun v1.4.0 هو أول إصدار مبني على Rust.

1 النتيجة: من تسرب ذاكرة 6.7 جيجابايت إلى استقرار 609 ميجابايت

كان Bun في البداية مشروعًا مبنيًا على Zig، ويشمل نطاقًا واسعًا جدًا: فهو مُحوّل لـ JavaScript وTypeScript، ومُجمّع، ومُدير حزم، ومشغّل اختبارات، ومحرّك تحليل وحدات، وعميل HTTP وWebSocket، كما يُنفّذ طبقة واجهة برمجة تطبيقات Node.js. وقد كان هذا العرض الواسع للمنتج هو السبب في تجاوز عدد تنزيلات CLI لـ Bun 22 مليون مرة شهريًا، وحصوله على دعم من مشاريع أو شركات مثل Vercel وRailway وDigitalOcean وClaude Code وOpenCode.

لكن نفس هذا العرض يجلب بعض التحديات لـ Bun.

في Bun v1.3.14 على وجه التحديد، كان هناك مشكلة طويلة الأمد تسبب إزعاجًا للعديد من المستخدمين: عند تنفيذ مكالمات متتالية لـ Bun.build()، تتراكم الذاكرة دون إطلاقها أبدًا. كل بناء يُهدر حوالي 3 ميغابايت، وهو ما يبدو قليلاً، لكن إذا كنت تشغل خادم تطوير يُحفّز بناءً لكل طلب، فستُستهلك الذاكرة تدريجيًا حتى ينهار العملية.

في الاختبارات العملية، استهلكت الذاكرة 1.9 جيجابايت بعد 500 بناء، و3.5 جيجابايت بعد 1000 بناء، و5.1 جيجابايت بعد 1500 بناء، وارتفعت إلى 6.7 جيجابايت بعد 2000 بناء.

هذا مجرد قمة جبل الجليد من مشكلات الذاكرة. في قائمة إصلاحات الأخطاء في الإصدار v1.3.14، قام سومنر بسرد قائمة طويلة من المشكلات:

عند استدعاء .reset() في وحدة zlib، إذا كان هناك .write() غير متزامن قيد التنفيذ في مجموعة الخيوط، فإن العملية ستتعطل بسبب "استخدام بعد تحرير الذاكرة"؛ في وحدة http2، يؤدي تفعيل دعوات JavaScript المتداخلة إلى إعادة تجزئة جدول التجزئة، مما يتسبب في فساد مؤشرات التدفق الداخلية؛ عند استخدام UDPSocket.sendMany() أثناء التكرار، إذا غيّر كود المستخدم حالة الاتصال عبر دعوات valueOf أو toString، فسيحدث كتابة خارج الحدود؛ عندما يفشل تخصيص مخزن الإخراج في crypto.scrypt، لا يتم تحرير الدعوة أو مخزن كلمة المرور المحمية أبدًا؛......

السمة المشتركة لهذه الأخطاء واضحة جدًا — فهي تشير تقريبًا جميعها إلى نفس المصدر الأساسي: مزج GC مع إدارة الذاكرة اليدوية في نفس البرنامج.

المحركات الحديثة مثل JavaScriptCore (وV8) لديها قواعد صارمة جدًا للتعامل مع الاستثناءات وجمع النفايات، بينما Zig لا تدير الذاكرة تلقائيًا كما يفعل C. عندما تتداخل هاتان المنهجيّتان في نفس العملية، يجب مراجعة كل تخصيص للذاكرة سطرًا بسطر: أين تُحرَّر هذه البايتات؟ كيف نضمن أنها تُحرَّر مرة واحدة فقط؟ هل تم التحقق من استثناءات JavaScript بشكل صحيح؟ هل هذا المؤشر الخاضع لإدارة جمع النفايات مرئي لمحقق المكدس التحفظي؟ هل هذا ذاكرة مدارة بواسطة جمع النفايات أم ذاكرة مدارة يدويًا؟

الأمر الأكثر إثارة للقلق أن الفريق لم يكن غير مُجتهد. فقد قاموا بتعديل مُجمّع Zig وإضافة دعم Address Sanitizer (ASAN)، وتشغيل اختبارات ASAN في CI مع كل إرسال، وبناء ReleaseSafe على Windows، وإجراء اختبارات ضبابية على مدار 24/7 باستخدام Fuzzilli، بالإضافة إلى عدد كبير من اختبارات التسريبات الذاكرة الشاملة. ومع ذلك، استمرت تقارير التوقف المفاجئ في التدفق دون انقطاع.

كتب سومنر: "قائمة إصلاحات الأخطاء الخاصة بنا تجعلنا نشعر بسوء، وأنا متعب من النوم مع قلق بشأن انهيار Bun." وهو لا يلوم Zig — فمستخدمو Zig الآخرون لم يواجهوا مشكلات مشابهة مع Bun، لأن دمج نظام جمع القمامة مع إدارة الذاكرة اليدوية هو طلب نادر جدًا، ولم تُصمم له تقريبًا أي لغة.

أما إصدار Rust، فقدم نتيجة متمثلة في: تنفيذ 2000 مرة Bun.build() مع استقرار الذاكرة عند 609 ميجابايت.

بالإضافة إلى حل مشكلة تسرب الذاكرة بشكل جذري، فإن إعادة الكتابة باستخدام Rust جلبت تحسينات أخرى في عدة أبعاد.

فيما يتعلق بالاستقرار، أصلح الإصدار v1.4.0 128 خطأً قابلًا للتكرار في الإصدار v1.3.14، بدءًا من تسرب الذاكرة وصولًا إلى الانهيار وخطأ عرض الألوان في نص المساعدة.

من حيث الحجم، مع إعادة الكتابة باستخدام Rust وتغييرات ICU وطي نفس الكود، تقلص حجم ملفات Bun الثنائية بنسبة حوالي 20% على Linux وWindows.

من حيث الأداء، تحسّنت الأداء بنسبة 2% إلى 5% بشكل عام. ارتفع Bun.serve من 169,600 req/s إلى 177,700 req/s، وارتفع node:http من 103,800 إلى 108,500. في السيناريوهات العملية، انخفض next build من 13.62 ثانية إلى 13.03 ثانية، وانخفض تجميع tsc بالدُفعات من 0.94 ثانية إلى 0.89 ثانية.

وبعد إصدار Claude Code على أساس Rust Bun، انخفض وقت التشغيل على Linux من 517 مللي ثانية إلى 464 مللي ثانية، أي أسرع بنسبة 10% تقريبًا.

2 طريقة: 64 كلاود، 11 يومًا، 50 سير عمل

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

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

كل مهمة لها سياق (مثل تذكرة Jira أو مشكلة GitHub)، ويكتب Claude الكود بناءً على هذا السياق، ثم يراجع الكود مراجعان آخران (وهما أيضًا Claude)، وأخيرًا يُطبَّق التغذية الراجعة. بعد الانتهاء، يُؤخذ المهمة التالية.

هذا النمط يمتد عبر عملية إعادة الكتابة بأكملها. كل سير عمل مسؤول عن هدف محدد:

• قم بإنشاء دليل نقل لخرائط أنماط ونوع Zig إلى أنماط ونوع Rust؛
• قم بتحويل كل ملف .zig إلى ملف .rs بشكل آلي، وتوافق مع PORTING.md و LIFETIMES.tsv؛
• إصلاح أخطاء التجميع لكل crate؛
• اجعل الأوامر الفرعية مثل bun test أو bun build تعمل؛
• اجعل كل اختبار في مجموعة الاختبارات الكاملة لـ Bun يمر؛ قم بعدة جولات من إعادة الهيكلة الكبيرة والتنظيف.

في ذروة العمل، كان سومنر يشغل 4 سير عمل في نفس الوقت، كل سير عمل يحتوي على 16 نسخة من Claude، مما أدى إلى عمل 64 نسخة من Claude بالتوازي عبر 4 أشجار عمل، حيث كانت كل منها ترسل وتُ推送 الملفات. وفي أقصى ذروة، كان Claude يكتب حوالي 1300 سطر من الشيفرة في الدقيقة.

إن تصميم الفصل بين "المُنفّذ / المُراجع" هذا هو المفتاح. يرغب كلاود في جعل الكود الخاص به مقبولاً، تمامًا مثل المهندسين البشريين الذين لديهم تحيزات. لذا يتم فصل المراجعين عن المُنفّذين تمامًا — حيث ينظر المراجعون فقط إلى فروقات الكود، ولا يرون عملية استدلال المُنفّذ، ويُبلغون صراحةً بـ "افترض أن الكود خاطئ". لكل مُنفّذ هناك أكثر من مُراجعين متعارضين، ومهمة المراجعين الوحيدة هي العثور على الأخطاء.

إكمال كتابة الكود هو فقط الخطوة الأولى. إن كود Zig هو وحدة تجميع واحدة، بينما يتم تقسيم كود Rust إلى حوالي 100 crate لتسريع عملية التجميع، مما تسبب في تبعيات دائرية وأدى إلى ظهور حوالي 16000 خطأ تجميع في وقت واحد عند تشغيل cargo check. هذا كارثة لشخص واحد، لكنه قائمة مهام قابلة للتعامل معها من قبل 64 نسخة من Claude تعمل بالتوازي. يتم تجميع الأخطاء حسب crate، ويتم تشغيل cargo check لكل crate، حيث يقوم نسخة واحدة من Claude بإصلاح الخطأ، واثنتان تراجعان التغييرات، ونسخة واحدة تطبق التعديلات.

بعد ذلك، قم بتشغيل bun --version، ثم bun test. تعمل سلسلة الاختبارات على تشغيل 100 ملف اختبار عشوائي في كل مرة، موزعة على 4 أشجار عمل. تتضمن مجموعة الاختبارات أيضًا أنواعًا متعددة: بعض الاختبارات تستمر لأكثر من دقيقة، وبعضها يستهلك عدد اتصالات TCP النظامية، وبعضها ينشئ حوالي 10000 عملية. استخدم Sumner systemd-run لإنشاء cgroup لتحديد الموارد، لكن الجهاز تعطل عدة مرات بسبب نفاد مساحة القرص.

بعد يومين، انخفض عدد اختبارات الفشل على منصة Linux من 972 إلى 23. وبعد يوم ونصف، أصبحت Linux خضراء بالكامل. بعد خمسة أيام، نجح جميع المنصات الستة — Linux x64 و Linux arm64 و macOS x64 و macOS arm64 و Windows x64 و Windows arm64 — بالكامل.

في 14 مايو، تم دمج PR #30412 رسميًا، واجتازت مجموعة الاختبارات جميع الاختبارات دون تخطي أو حذف أي اختبار.

3 مخاوف: 13,000 سطر من الشيفرة غير الآمنة وغير القابلة للمراجعة السطرية

ومع ذلك، يعترف سومنر أن هذا العمل لم ينتهِ حقًا.

حتى الآن، يشغل كود Rust الخاص بـ Bun حوالي 4% داخل كتل unsafe، مع حوالي 13,000 كلمة مفتاحية unsafe، موزعة على حوالي 27,000 سطر من الكود، بينما يبلغ إجمالي كود Rust حوالي 780,000 سطر. حيث تشكل 78% من كتل unsafe سطرًا واحدًا فقط، عادةً ما يكون مؤشرًا من C++ أو استدعاء واحد لمكتبة C.

يتوقع أن يؤدي إعادة الهيكلة اللاحقة إلى خفض هذا النسبة. لكن أحد الأشخاص قام بحساب: حوالي 350 ألف سطر من الكود uv، مع وجود فقط 73 استدعاءً غير آمن. وعدد الاستدعاءات غير الآمنة في Bun هو 178 ضعف عدد استدعاءات uv. يصعب تفسير هذا الفرق بـ"الحاجة إلى استدعاء مكتبات C".

وتم كشف السلوك غير المعرف أيضًا في كود Rust الآمن. وهذا أصعب في تصحيح الأخطاء من C++، لأنك ستظن أن الكود الآمن لا يمكن أن يحتوي على مشاكل.

قام فريق Bun بعد ذلك بتحويل PathString::init إلى unsafe fn.

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

على سبيل المثال، يبدو هذان المقتطفان من الكود متشابهين، لكن سلوكهما مختلف تمامًا. إن assert في Zig هي دالة، لذا يتم تشغيل معاملاتها في كل بناء. أما debug_assert! في Rust فهو ماكرو، لذا يتم حذف التعبير بأكمله (بما في ذلك استدعاء الدالة) في الإصدارات الإصدارية insert_stale.

على الرغم من أن جميع المشكلات قد تم إصلاحها، إلا أن هذا لا يعني أن ملايين الأسطر من كود الذكاء الاصطناعي لا تحتوي على مشكلات أخرى.

من يفعل ذلك بشكل طبيعي؟ من ينقل تطبيق الإنتاج الخاص به فورًا بعد إعادة كتابته بالكامل أثناء التشغيل؟ من يعتقد أن الإصدار 1.4 لم يُدخل أي أخطاء جديدة أو تغييرات في السلوك، فهو مُتَفَاؤل جدًا.

شيء آخر لا يمكن تجاهله هو مراجعة الكود. لا يمكن للبشر مراجعة 1 مليون سطر من التغييرات سطرًا بسطر — حتى لو استغرق الأمر دقيقة واحدة لكل سطر، فسيستغرق الأمر 11.7 يومًا متواصلة؛ وبسرعة مراجعة الكود الفعلية (200 سطر في الساعة)، سيستغرق الأمر أكثر من عامين لإكمالها.

المراجعون الرئيسيون لهذا PR هم claude[bot] و coderabbitai[bot]. كما اعترف سومنر بنفسه أن أسلوب مراجعته هو "التحقق من أن وكيل المراجعة التحديدي قام بتحديد الفروق بدقة، وضمان الالتزام بإرشادات التحويل، مع قراءة يدوية لكثير من الشيفرة". لكنه لم يحدد كم "كثير".

هناك مشكلة أخرى لا يمكن تجنبها: تم استحواذ Anthropic على Bun في ديسمبر 2025، والأداة الوحيدة الفعالة حقًا للحفاظ على هذا المستودع هي Claude نفسها. يقول بعض أعضاء المجتمع إن هذا لم يعد يُعتبر مشروعًا مفتوح المصدر بالمعنى التقليدي — إذا أردت تقديم طلب PR إلى Bun، فعليك الاشتراك في Anthropic أولاً، أو الاعتماد على عدد قليل من الأعضاء الأساسيين الذين فهموا بالفعل الكود المُنشأ بواسطة الذكاء الاصطناعي.

هل يستحق 165,000 دولار مقابل سنة من العمل؟

كما كشف سومر في مدونته أن تكلفة إعادة كتابة الـ API بلغت حوالي 165 ألف دولار، أي ما يعادل عام عمل من ثلاثة مهندسين. وأثار هذا الرقم نقاشات حادة على Hacker News.

يعتقد البعض أن هذه التكلفة في الواقع مربحة جدًا. فبـ 165 ألف دولار، لا يمكنك توظيف سوى عدد قليل من مهندسين بدوام كامل في سيليكون فالي، ناهيك عن مهندسين من مستوى شركة Anthropic. ووفقًا لبيانات الرواتب على levels.fyi، فإن الحزمة الإجمالية لمهندس في Anthropic قد تصل إلى 500 ألف دولار أو أكثر. حتى لو افترضنا أن متوسط الراتب السنوي لـ 50 مهندسًا هو 336 ألف دولار، فهذا يعادل حوالي 1292 دولارًا يوميًا. وبعمل 50 شخصًا بشكل متواصل لمدة 11 يومًا، تصبح تكلفة العمالة وحدها قريبة من 710 آلاف دولار، دون احتساب المزايا أو مساحات المكاتب أو المعدات وغيرها من التكاليف الإدارية.

لكن سومر استخدم "النسخة ما قبل الإصدار من Claude Fable 5"، وهي نموذج متقدم لم يُفتح بعد للجمهور وقد يكون خاضعًا لقيود التصدير. لذا فإن تسعير واجهة برمجة التطبيقات هو فقط الرقم الذي يراه المستخدم النهائي، بينما يقف خلفه استثمار ضخم من Anthropic في البحث والتطوير. كما أشار آخرون إلى أن تبسيط التكلفة إلى تسعير واجهة برمجة التطبيقات يهدف إلى التقليل من الإسهامات الحقيقية. إذا تم تضمين تكاليف تطوير النموذج، وتدريبه، واستثمار الحوسبة، والموارد الهندسية، فمن المؤكد أن التكلفة الإجمالية النهائية ستكون مرتفعة جدًا، وربما تتجاوز 1.5 مليون دولار.

ومن الناحية الحالية، على الرغم من أن 165,000 دولار مقابل سنة من العمل تبدو مربحة من الناحية المحاسبية.

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