Bun, 2026 Mayıs'ta Zig'den Rust'a büyük bir kod geçişi tamamladı ve 11 gün içinde 1 milyondan fazla satır kod değişikliği ve 6.778 commit gerçekleştirdi. Geçişi 64 Claude paralel olarak çalıştırmakla gerçekleştirdi ve 165.000 dolarlık API maliyeti harcandı. Geçişten sonra bellek sızıntısı sorunu temel düzeyde çözüldü; 2.000 derlemeden sonra bellek kullanımı 6,7 GB'dan 609 MB'a sabitlendi, performans %2 ile %5 arasında arttı ve ikili dosya boyutu yaklaşık %20 azaldı. Ancak kodda yaklaşık 13.000 adet unsafe anahtar kelimesi bulunuyor ve bu, benzer projelerin 178 katı; bilinen 19 adet geri dönüşüm sorunu var ve 1 milyon satır değişiklik insanlar tarafından satır satır denetlenemiyor. Şu anda Bun, Anthropic tarafından satın alındı.

Yazan: InfoQ

Mayıs 2026'da, Bun projesi yazılım geliştirme tarihinin neredeyse nadir bir büyük kod taşıması gerçekleştirdi.

Bu geçiş, 3 Mayıs'ta başlatıldı ve 14 Mayıs'ta ana kola resmen entegre edildi, sadece 11 gün sürdü. Kod yazmak 6 gün sürdü ve tüm süreç açık oldu. Ancak Jarred Sumner'ın blog yazısıyla özeti yazmak neredeyse bir ay sürdü, bu da kod yazma süresinden çok daha uzun.

Bu JavaScript çalışma zamanı, yorumlar hariç orijinalde 535.496 satır Zig koduna sahipti; aynı zamanda yaklaşık %20'si C++ ile yazılmış ve birçok C/C++ kütüphanesi entegre edilmişti. Bu, AI kullanılarak Rust'a yeniden yazıldı ve süreç boyunca 1 milyondan fazla satır kod değişikliği, 6.778 commit gerçekleştirildi ve Claude Code içinde yaklaşık 50 dinamik iş akışı çalıştırıldı.

Sumner'in açıkladığı verilere göre, bu yeniden yazma işlemi API katmanında 5,9 milyar önbelleğe alınmamış giriş tokeni, 690 milyon çıkış tokeni ve 72 milyar önbelleklenmiş giriş tokeni okuması消耗 etti ve API fiyatlandırmasına göre yaklaşık 165.000 ABD doları maliyeti oluşturdu.

Sumner, bunun şu anki teknolojiyle ulaşılabilen en ileri seviye olduğunu söyledi. 3 tamamen Bun kod tabanı ile aşina mühendisin bu geçişi elle tamamlamasının yaklaşık bir yıl süreceğini ve bu yıl boyunca ekibin yeni özellikler geliştirme, hata düzeltme ve güvenlik düzeltmeleri yapma imkanının neredeyse olmayacağını tahmin etti.

Bu yeniden yazma sonrası, Bun v1.3.14 son Zig sürümü olacak ve Bun v1.4.0 ilk Rust sürümü olacaktır.

1 Sonuç: 6,7 GB bellek sızıntısından 609 MB sabit duruma geçiş

Bun, ilk olarak bir Zig projesi olarak başlamıştır ve çok geniş bir kapsama sahiptir: hem JavaScript ve TypeScript derleyicisi, hem de paketleyici, paket yöneticisi, test çalıştırıcı, modül çözücü, HTTP ve WebSocket istemcisi olup Node.js API katmanını da uygular. Bu geniş ürün yelpazesi, Bun'un CLI'sinin ayda 22 milyondan fazla indirilmesine ve Vercel, Railway, DigitalOcean, Claude Code ve OpenCode gibi projelerin veya şirketlerin desteklenmesine neden olmuştur.

Ancak aynı genişlik, Bun'a bazı zorluklar da getirdi.

Özellikle Bun v1.3.14'te, Bun.build() çağrılarının ardışık olarak yürütülmesi durumunda belleğin sürekli birikip asla serbest bırakılması sorunu uzun zamandır kullanıcıları rahatsız ediyordu. Her bir build yaklaşık 3 MB bellek sızıntısına neden oluyor; bu miktar az görünse de, her istekte bir build tetikleyen bir geliştirme sunucusu çalıştırıyorsanız, bellek yavaş yavaş tüketilir ve işlem sonunda çöker.

Gerçek testte, 500 yapılandırma sonrası bellek kullanımı 1,9 GB, 1000 sonrası 3,5 GB, 1500 sonrası 5,1 GB ve 2000 sonrası 6,7 GB'a yükseldi.

Bu, birçok bellek sorununun sadece bir küçük parçasıdır. Sumner, v1.3.14 hata düzeltme listesinde uzun bir sorun listesi sıraladı:

zlib modülünde .reset() çağrıldığında, hala bir asenkron .write() işlemi iş parçacığı havuzunda yürütülüyorsa, süreç "yığın serbest bırakıldıktan sonra kullanım" nedeniyle çöker; http2 modülünde iç içe JavaScript geri çağırma fonksiyonları, karma tablo yeniden karma işlemine neden olur ve dahili akış işaretçilerini geçersiz hale getirir; UDPSocket.sendMany() işlemi sırasında, kullanıcı kodu valueOf veya toString geri çağırma fonksiyonları aracılığıyla soket bağlantı durumunu değiştirirse, sınır dışı yazma gerçekleşir; crypto.scrypt, çıktı tamponu tahsisi başarısız olduğunda, geri çağırma ve korunan şifre tamponu asla serbest bırakılmaz; ......

Bu hataların ortak özelliği çok açık—neredeyse hepsi aynı kökene işaret ediyor: GC ile el ile bellek yönetiminin aynı yazılımda birlikte kullanılması.

Modern motorlar JavaScriptCore (ve V8), istisna işleme ve GC için son derece katı kurallara sahiptir; Zig ise C diline benzer şekilde belleği otomatik olarak yönetmez. Bu iki paradigmayı aynı süreçte birleştirdiğinizde, her bellek tahsisi satır satır incelenmelidir: Bu baytlar nerede serbest bırakılır? Sadece bir kez serbest bırakıldığı nasıl garanti altına alınır? JavaScript istisnaları doğru şekilde kontrol edildi mi? GC tarafından yönetilen bu işaretçi, konservatif yığın tarayıcısı için görünür mü? Bu GC belleği mi, yoksa elle yönetilen bellek mi?

Daha da endişe verici olan, ekibin çaba sarf etmediği değil; Zig derleyicisine Address Sanitizer (ASAN) desteği ekledikleri, her commit'te CI'da ASAN testlerini çalıştırdıkları, Windows'ta ReleaseSafe ile derledikleri, Fuzzilli ile 24/7 bulanık test yaptıkları ve büyük miktarda uçtan uca bellek sızıntısı testleri gerçekleştirdikleri. Bunlara rağmen, çökmelerle ilgili raporlar akış halinde devam ediyor.

“Hata düzeltme listemiz çok kötü hissettiriyor, Bun çökmesi endişesiyle uyumaya yorgunum,” diye yazdı Sumner. Zig’i suçlamıyor—diğer Zig kullanıcıları, GC’yi elle bellek yönetimiyle karıştırmak gibi çok nadir bir ihtiyaç olmadığı için Bun gibi sorunlarla karşılaşmıyor ve bu ihtiyaç için neredeyse hiçbir dil tasarlanmamıştır.

Rust sürümünün sunduğu sonuç ise: 2000 kez Bun.build() yürütüldüğünde, bellek kullanımı 609 MB sabit kalır.

Bellek sızıntısı sorunu temel olarak çözüldüğü gibi, Rust'a yeniden yazım diğer birkaç boyutta da iyileştirmeler getirdi.

Stabilite açısından, v1.4.0, v1.3.14'te tekrarlanabilir olan 128 hata düzeltildi; bellek sızıntısından çökmelere ve renk gösterim hatalarına kadar olan tüm sorunlar çözüldü.

Hacim açısından, Rust ile yeniden yazma, ICU değişiklikleri ve aynı kod katlaması ile Bun, Linux ve Windows'ta ikili dosya boyutunda yaklaşık %20 azalma sağladı.

Performans açısından genel olarak %2 ila %5 artış sağlandı. Bun.serve, 169.600 req/s'ten 177.700 req/s'e yükseldi; node:http, 103.800'den 108.500'e çıktı. Gerçek uygulama senaryolarında, next build 13,62 saniyeden 13,03 saniyeye düştü; tsc toplu derleme 0,94 saniyeden 0,89 saniyeye indi.

Rust Bun tabanlı sürümün piyasaya sürülmesinden sonra Claude Code'un Linux'taki başlatma süresi 517 ms'den 464 ms'ye düştü, yaklaşık %10 daha hızlı.

2. Yöntem: 64 Claude, 11 gün, 50 iş akışı

Sumner, geleneksel "AI ile kod yazdırma" yönteminden farklı olarak bunu nasıl başardı, muhtemelen en dikkat edilmesi gereken kısım.

Sumner, süreci yaklaşık 50 dinamik iş akışına böldü, her bir iş akışı bir döngüdür. Bu modeli blogunda sahte kodla açıkladı:

Her görevin bir bağlamı vardır (örneğin bir Jira biletı veya GitHub sorunu), Claude bu bağlamı temel alarak kod yazar, ardından iki inceleyici (aynı şekilde Claude) kodu inceler ve geri bildirim uygulanır. Tamamlandıktan sonra bir sonraki görev alınır.

Bu model, tüm yeniden yazma süreci boyunca devam etti. Her iş akışı, belirli bir hedefi sorumlu tutuyor:

• Zig'in desenlerini ve türlerini Rust'ın desenlerine ve türlerine eşleyen bir portlama kılavuzu oluşturun;
• Her .zig dosyasını mekanik olarak bir .rs dosyasına taşıyın ve PORTING.md ile LIFETIMES.tsv'yi eşleştirin;
• Her crate için derleme hatalarını düzeltin;
• bun test veya bun build gibi alt komutları çalıştırmak;
• Bun'un test suite'indeki her testin geçmesini sağlayın; birkaç büyük yeniden yapılandırma ve temizlik turu yapın.

Zirve döneminde, Sumner aynı anda 4 iş akışı çalıştırdı; her iş akışında 16 Claude bulunuyordu ve toplamda 64 Claude, 4 farklı iş ağacında paralel olarak çalışarak dosyaları gönderip itiyordu. En yüksek noktada, Claude dakikada yaklaşık 1300 satır kod yazıyordu.

Bu “gerçekleştirici / inceleyici” ayrımı tasarımı kritiktir. Kod yazan Claude, insan mühendisleri gibi kodun kabul edilmesini ister. Bu nedenle inceleyiciler ve gerçekleştiriciler tamamen ayrılmıştır—inceleyiciler yalnızca kod farklarını görür, gerçekleştiricinin akıl yürütme sürecini görmez ve açıkça “kodun yanlış olduğunu varsayın” olarak bilgilendirilir. Her gerçekleştiriciye iki veya daha fazla karşıt inceleyici atanır ve inceleyicilerin tek görevi hataları bulmaktır.

Kodun yazılması sadece ilk adımdır. Zig kodu tek bir derleme birimidir, ancak Rust kodu derleme hızını artırmak için yaklaşık 100 crate'e bölünmüştür; döngüsel bağımlılıklar nedeniyle cargo check, bir seferde yaklaşık 16.000 derleme hatası üretir. Bu, bir insan için bir felaket olur, ancak 64 paralel çalışan Claude için işlenebilir bir iş kuyruğudur. İş akışı, hataları crate'lere göre gruplar, her crate için ayrı ayrı cargo check çalıştırır, bir Claude hataları düzeltir, iki tane inceleyip, bir tane de değişiklikleri uygular.

Sonra bun --version komutunu çalıştırın, ardından bun test komutunu çalıştırın. Test iş akışı, her seferinde rastgele 100 test dosyasını 4 çalışma ağacına bölerek çalıştırır. Test suite'i ayrıca çeşitli türlerde testler içerir: bazı testler bir dakikadan uzun sürer, bazıları sistem TCP bağlantı sayısını tüketer, bazıları yaklaşık 10.000 işlem çatallar. Sumner, kaynakları sınırlamak için systemd-run ile cgroup oluşturdu, ancak makine hala disk alanı tükenmesi nedeniyle birkaç kez çöktü.

İki gün sonra, Linux platformundaki başarısız testler 972'den 23'e düştü. Bir buçuk gün sonra, Linux tamamen yeşil oldu. Beş gün sonra, tüm altı platform—Linux x64, Linux arm64, macOS x64, macOS arm64, Windows x64, Windows arm64—başarıyla geçti.

14 Mayıs'ta PR #30412 resmen birleştirildi ve test suite tamamı geçti, hiçbir test atlanmadı veya silinmedi.

3 Gizli endişe: 13.000 adet güvensiz ve satır satır denetlenemeyen kod

Ancak Sumner, bu işin gerçekten bitmediğini de kabul ediyor.

Şu ana kadar, Bun'un Rust kodunun yaklaşık %4'ü unsafe bloklarında yer alıyor, yaklaşık 13.000 unsafe anahtar kelimesi, yaklaşık 27.000 satır kod içinde dağılmış durumda, Rust toplam kod miktarı ise yaklaşık 780.000 satır. unsafe bloklarının %78'i yalnızca bir satırdan oluşuyor ve genellikle bir C++ işaretçisi ya da bir C kütüphane çağrısı içeriyor.

Sonraki yeniden yapılandırmaların bu oranı düşüreceğini tahmin ediyor. Ancak biri bir hesap yaptı: uv yaklaşık 350.000 satır kod içeriyor ve sadece 73 adet unsafe çağrısı var. Bun'un unsafe sayısı, uv'nin 178 katı. Bu fark, "C kütüphanelerine çağrı yapılması gerektiği" gerekçesiyle açıklanamaz.

Ayrıca güvenlikli Rust kodunda da tanımsız davranış ortaya çıktı. Güvenli kodun sorun çıkaramayacağını düşünmeniz nedeniyle C++'tan daha zor hata ayıklanır.

Bun ekibi ardından bu sorunda PathString::init'i unsafe fn olarak değiştirdi.

Sumner, bu yeniden yazımın 19 bilinen geri dönüşüm sorununu getirdiğini kabul etti ve çoğu geri dönüşüm sorununun sözdizimi aynı ancak anlamları farklı kodlardan kaynaklandığını belirtti.

Bu iki kod parçası birbirine çok benzer gibi görünse de davranışları tamamen farklıdır. Zig kodundaki assert bir fonksiyondur, bu nedenle parametreleri her derlemede çalışır. Rust kodundaki debug_assert! ise bir makrodur, bu nedenle yayın sürümlerinde tüm ifade (fonksiyon çağrısı dahil) kaldırılır insert_stale.

Sorunlar düzeltilmiş olsa da, bu, milyonlarca satır AI kodunun başka sorunları olmadığını göstermez.

Bir uygulamanın çalışma zamanı tamamen yeniden yazıldıktan hemen sonra üretim uygulamasını ona taşıyan normal biri var mı? 1.4 sürümünün yeni hatalar içermediğini veya davranış değişiklikleri getirmediğini düşünmek çok naif olur.

Gözden geçirilmesi gereken bir başka önemli nokta kod incelemesidir. 1 milyon satırlık değişiklik, insanlar tarafından satır satır incelenemez—her satırı bir dakikada okusalar bile 11,7 gün boyunca sürekli okumak gerekir; gerçek kod inceleme hızına göre (saatte 200 satır), bunu tamamlamak iki yıldan fazla sürer.

Bu PR'nin inceleyicileri çoğunlukla claude[bot] ve coderabbitai[bot]'di. Sumner, kendi inceleme yöntemini "mücadeleci inceleme agentinin farkları doğru şekilde yakalayıp yakalamadığını kontrol etmek, dönüştürme kılavuzlarının uygulanmasını sağlamak ve aynı zamanda kendisi de oldukça fazla kodu manuel olarak okumak" şeklinde tanımladı. Ancak "çok fazla" ne kadar olduğunu belirtmedi.

Karşılaşılmaz bir sorun daha var: Bun, 2025 Aralık'ta Anthropic tarafından satın alındı; bu kod deposunu gerçekten etkili bir şekilde koruyabilecek araç, neredeyse yalnızca Claude'dir. Toplulukta bazıları, bunun artık geleneksel bir açık kaynak projesi sayılmadığını söylüyor—Bun'a bir PR göndermek istiyorsanız, önce Anthropic'e abone olmalısınız ya da AI tarafından üretilen kodu anlayan birkaç temel üyenin umuduna yapışmalısınız.

Yıllık bir iş yükü için 165.000 dolar değer mi?

Sumner, blogda bu yeniden yazılan API'nin maliyetinin yaklaşık 165.000 dolar olduğunu, yani 3 mühendisin bir yıl boyunca yaptığı işe eşit olduğunu açıkladı. Bu rakam, Hacker News'te yoğun bir tartışma yarattı.

Bazıları bu maliyetin aslında çok avantajlı olduğunu düşünüyor. 165.000 dolar, Silicon Valley'de birkaç tam zamanlı mühendis almak için yeterli değil, özellikle Anthropic gibi bir şirketin mühendisleri için daha da az. Levels.fyi'deki maaş verilerine göre, Anthropic mühendislerinin toplam paket ücreti muhtemelen 500.000 dolar veya daha fazla olacak. 50 mühendisin yıllık ortalama maaşının 336.000 dolar olarak kabul edilmesi durumunda, bu tutar günlük yaklaşık 1.292 dolar eder. 50 kişinin 11 gün boyunca sürekli çalışması yalnızca insan kaynakları maliyeti olarak yaklaşık 710.000 doları aşar; bu tutar, sosyal güvence, ofis alanı, ekipman ve diğer yönetim giderlerini içermez.

Ancak Sumner, genel halka açık olmayan ve muhtemelen ihracat kontrolleri altındaki ileri bir model olan "Claude Fable 5 ön sürümünü" kullanıyor. Bu nedenle API fiyatlaması, son kullanıcıların gördüğü rakamdan ibarettir; arkasında Anthropic'in yaptığı büyük ölçekli araştırma ve geliştirme yatırımları vardır. Bazıları, maliyetleri sadece API fiyatlamasına indirgemekle gerçek yatırımları kasıtlı olarak küçümsediğini belirtiyor. Model geliştirme maliyetleri, eğitim maliyetleri, hesaplama kaynakları ve mühendislik personeli dahil olmak üzere tüm maliyetleri hesaba katarsak, toplam maliyetin kesinlikle yüksek olacağını ve muhtemelen 1,5 milyon doları aşacağını düşünüyoruz.

Ayrıca şu anda 165.000 dolarlık bir tutarın bir yılın çalışma yüküne karşılık geldiğini görünce, hesaplamalara göre oldukça avantajlı görünüyor.

Ancak gerçek maliyet bu faturada yer almıyor. Bu kod deposunda 6.778 gönderim var ve kimse tamamını baştan sona okumadı; şu anda her şey yolunda olsa da, altı ay sonra ne olacak? Bir sabah üçte aniden ortaya çıkan garip bir eşzamanlılık sorununda, nöbetçi mühendis, kendi iç mantığını bile açıklayamadığı bir sistemle karşı karşıya kalacak. Gelecekte tüm bunların AI ile bakımını yapmak zorunda kalınacak; bakım maliyeti nasıl hesaplanır, aslında oldukça zor.