فرق سرعة البناء بين Rust وZig في Bun يعود في جزء كبير منه إلى إعداد LTO
فرق نُسب إلى اللغة كان في جزء كبير منه فرق إعداد، والإعداد نفسه لم يكن في مستودع المشروع أصلًا، بل في مكتبة تُحمَّل جاهزة.
وسم
فرق نُسب إلى اللغة كان في جزء كبير منه فرق إعداد، والإعداد نفسه لم يكن في مستودع المشروع أصلًا، بل في مكتبة تُحمَّل جاهزة.
الجديد ليس أن الفريق كسر كودًا قائمًا، بل أنه قاس حجم الكسر ونشره قبل اتخاذ القرار، فصار الخلاف على الحكم لا على المعلومات.
تكلفة إدخال لغة جديدة إلى codebase قديم ليست في الصياغة ولا في إقناع الفريق، بل في جعل مخرجاتها جزءًا أصيلًا من أدوات البناء والتصحيح القائمة.
الوكيل يفهم شكل الاختبار لا جوهره، والـ skills الكبيرة المضافة لتحسينه قد ترفع الفاتورة يوميًا دون أي تحسن في صحة الكود.
اعتماد المطورين على الطباعة ليس كسلًا ولا تفضيلًا شخصيًا، بل مؤشر على أن أدوات الـ debugging لم تواكب اللغة بعد.
أدوات JavaScript صارت تُكتب بلغات أخرى، والانتقال إلى الأداة الأسرع هنا تغيير سطر في الإعدادات لا إعادة كتابة للمشروع.
أغلب عمل Rust الجاد هو استبدال كود C قائم قطعة بعد قطعة، وكل فجوة في التوافق كانت تترك سطرًا من C يعيش في المشروع سنوات.
مصدر السرعة ليس اللغة وحدها بل طريقة إدارة الذاكرة والاندماج داخل أداة البناء، والطبقة التي تمر على كل ملف في أدوات الواجهات تنتقل تدريجيًا إلى Rust.
كانت كلفة الكود المتضخم تُدفع من وقت المطورين فيسهل تأجيلها، ومع وكلاء AI صارت تظهر أرقامًا في فاتورة شهرية.
عبارة «متوافق مع Postgres» وعد يخص الواجهة لا المحرك، والمواضع التي يختلف فيها المحرك غالبًا لا تظهر إلا في بيئة production.
إعادة كتابة كانت مستحيلة على فريق صغير صارت ممكنة بالمال، لكنها تنتج codebase يعمل ولم يقرأه أحد في الفريق سطرًا سطرًا.
أمان الذاكرة ليس مسألة أكاديمية: إعادة كتابة الكود الذي يقرأ الصور القادمة من الإنترنت بلغة Rust تغلق فئة كاملة من الهجمات على المتصفح.