Bun שחררה קוד AI לא בטוח (unsafe)
Bun שכתבה לאחרונה את הליבה שלה ב-Rust. הם גם הוסיפו multithreading ניסיוני. אלו צעדים גדולים. עם זאת, השיטה שבה נעשה שימוש כדי להשיג את המטרות הללו מדאיגה.
צוות Bun הודה ש-Claude AI כתב חלק גדול מכתיבה מחדש ב-Rust. השינוי הזה הוסיף למאגר הקוד למעלה מ-13,000 בלוקים של unsafe. הוא גם שוחרר ללא garbage collector מקבילי (concurrent).
בתכנות מערכות, קוד unsafe עוקף את בטיחות הזיכרון (memory safety). בלוק unsafe אחד הוא סיכון. שלושה עשר אלף בלוקים מ-AI הם נטל.
אני מבין את הצורך במהירות. צוותים קטנים חייבים לנוע מהר כדי להתחרות ב-Node.js וב-Deno. אך מהירות ללא זהירות היא מסוכנת.
כל בלוק unsafe הוא הבטחה לגישה תקינה לזיכרון. כש-AI כותב את הקוד, מי חותם על ההבטחה הזו?
הסיכונים ברורים:
- לקוד AI חסר היגיון אנושי לניהול זיכרון.
- יצירה במהירות גבוהה דורשת סקירה (review) במהירות גבוהה.
- היעדר garbage collector מקבילי הופך עומסי עבודה מרובי-תהליכונים (multithreaded) ללא יציבים.
Runtime אינו ספרייה פשוטה. הוא הבסיס לכל האפליקציה שלך. אתה בוחר runtime על בסיס אמון. כשמרגישים שהתשתית היא ניסיונית, מפתחים חוזרים לכלים יציבים כמו Node.js.
אני משתמש בכלי AI מדי יום. אני מתייחס לקוד AI באותו אופן שבו אני מתייחס לקוד של מהנדס ג'וניור. הוא זקוק לסקירה שתואמת את ההשפעה שלו.
ההשפעה של multithreading בתוך runtime היא עצומה. שלושה עשר אלף בלוקים של unsafe זקוקים לשלושה עשר אלף סיבות טובות. הם לא זקוקים לשלושה עשר אלף אישורים עיוורים.
להיות שאפתן זה טוב. להיות רשלן עם קוד מערכות זה נטל.
האם היית מריץ 13,000 בלוקים של unsafe שנוצרו על ידי AI באפליקציית ה-production שלך? מה הגבול שלך באמון ב-AI עבור תשתיות?
קהילת למידה אופציונלית: https://t.me/GyaanSetuAi