Bun 1.4 Artık Rust ile Çalışıyor. Geçmeden Önce Test Rakamlarını Okuyun

20 Ağustos'ta Bun ekibi, runtime'ın Zig yerine Rust ile yazılmış ilk sürümü olan Bun 1.4'ü yayınladı. Sürüm daha düşük CPU ve bellek kullanımı, daha hızlı açılış ve Node.js uyumluluğunda büyük bir sıçrama vaat ediyor. Burada iki ders var: bir yeniden yazımın gerçekten ne zaman güvenli olduğu ve production trafiğini taşımadan önce uyumluluk rakamlarının nasıl okunması gerektiği.

Neler geldi#

Sürüm duyurusundaki öne çıkan rakamlar:

• Küçük bir hello-world uygulamasında boştaki CPU kullanımı 5 kat düşüyor. Claude Code'un production p99 CPU değeri %24'ten %10'a indi.
• HTTP sunucularında tepe bellek kullanımı Bun 1.3'e göre %13 ile %48 arasında daha düşük. 64 bağlantıyla 1.000.000 istek üzerinden ölçümde Fastify 233 MB'tan 120 MB'a, Express ise 169 MB'tan 92 MB'a düştü. Aynı testte Node.js 26 sırasıyla 156 MB ve 145 MB'ta kalıyor.
• Açılış Windows'ta 2,5 kat (15,5 ms), Linux'ta 2 kat (5,1 ms) daha hızlı.
• Sürüm, hepsi ilk olarak 1.3.x sürümlerinde gelen yerleşik özellikleri de bir araya topluyor: Bun.Image, headless tarayıcı otomasyonu için Bun.WebView, Bun.markdown, işletim sistemi seviyesinde zamanlanmış işler için Bun.cron ve node-pty'ye ihtiyaç duymadan pseudo-terminal sağlayan Bun.Terminal.

Yeniden yazım aslında nasıl yapıldı#

Ayrıntılar daha önceki bir yazıda, Rewriting Bun in Rust'ta anlatılıyor. Belirtilen gerekçe belirli bir hata sınıfı: garbage collector'ın yönettiği JavaScript değerleriyle manuel yönetilen belleğin bir arada kullanılmasından doğan use-after-free, double-free ve hata akışlarında "free etmeyi unutma" hataları. Güvenli Rust'ta bunlar ya derleyici hatasına dönüşüyor ya da Drop üzerinden otomatik temizleniyor. Jarred Sumner bunu şöyle özetliyor: "Compiler errors are a better feedback loop than a style guide." (Derleyici hataları, bir stil rehberinden daha iyi bir geri bildirim döngüsüdür.)

1.448 .zig dosyasının tamamının port edilip merge edilmesi 3 Mayıs'tan 14 Mayıs'a, 11 gün sürdü. Sumner, bir implementer'ı tek görevi kodun neden çalışmadığına dair gerekçe bulmak olan iki veya daha fazla karşıt (adversarial) reviewer ile eşleştiren Claude Code dinamik workflow'ları çalıştırdı. En yoğun anda yaklaşık 64 Claude instance'ı aynı anda çalışıyordu. Merge öncesi maliyet API fiyatlarıyla yaklaşık 165.000 dolardı; bilinen 19 regresyon vardı ve hepsi sonradan düzeltildi. Port bilinçli olarak birebir yapıldı; idiomatik refactoring 1.4'ten sonraya bırakıldı.

Hızı mümkün kılan agent'lardı, güvenliği değil. Bun'ın kendi test suite'i TypeScript ile yazılmış, yani runtime'ın hangi dille yazıldığına bağlı değil. Bu da port'a Linux üzerinde 60.624 test genelinde yaklaşık 1,39 milyon expect() çağrısından oluşan sabit bir spesifikasyon sağladı; tek bir test bile atlanmadı ya da silinmedi. Main'e merge etmek de bir release anlamına gelmiyordu: Rust build'i önce canary olarak çıktı, Claude Code haziran ayındaki v2.1.181'den beri bu build üzerinde yayınlanıyor ve ancak bundan sonra stable oldu.

Yeniden yazım ne zaman haklı çıkar#

Yeniden yazım önerilerinin çoğu "yeni dil daha güzel" noktasına varıyor. Bun'ın durumu dört açıdan farklı ve bunları bir kontrol listesi olarak kullanmaya değer:

• Hedef dilin ortadan kaldırdığı, adı konmuş bir hata sınıfı. "Daha iyi kod" değil; derleyicinin artık reddedeceği belirli bir kusur kategorisi.
• Implementasyondan bağımsız, çalıştırılabilir bir spesifikasyon. Testleriniz iç yapıya bağımlıysa kodla birlikte onlar da yeniden yazılır ve davranışın değişmediğine dair kanıtınızı kaybedersiniz.
• Sürüm numarasından önce production'da pişirme süresi. Canary build'ler ve büyük bir first-party tüketici, riski genel kullanıcılardan önce üstlendi.
• Önce birebir port et, sonra refactor et. Çeviriyi yeniden tasarımla karıştırmak her diff'i review edilemez hale getirir.

Kod üretmek ucuzladı. Doğrulamak ucuzlamadı. Asıl işi karşıt reviewer'lar ve dilden bağımsız test suite'i yaptı. Bir diff üzerinde birden fazla AI reviewer'ı deterministik kapılarla çalıştıran CLI aracım Quorate'i de aynı varsayım üzerine kurdum: agent'ın yazdığı kod, onu kontrol eden mekanizma kadar güvenilirdir.

Node uyumluluk rakamlarını okumak#

Bun 1.4, Node'un kendi test suite'inden 1.517 yeni testi geçiyor. node:http 415 testin 403'ünü, node:fs 358 testin 349'unu ve node:cluster 88 testin 85'ini geçiyor. node:events, node:trace_events ve node:sqlite %100'de. Yazı, Bun'ın henüz Node ile %100 uyumlu olmadığını açıkça söylüyor.

%97 iyi bir rakam, ama bu testleri sayıyor; o yüzeyin ne kadarını kullandığınızı değil. Başarısız olan 12 node:http testi hiç karşılaşmayacağınız uç durumlar da olabilir, tam olarak proxy'nizin dayandığı davranışlar da. Bir servisi taşımadan önce şunları kontrol ederdim:

• Servisin hangi node: modüllerini ve native addon'ları kullandığı ve başarısız testlerin bunları kapsayıp kapsamadığı.
• Kendi test ve contract suite'leriniz; sadece laptop'ta bun test'in geçmesi değil, Bun üzerinde çalışan bir instance'a karşı koşturulmuş halleri.
• Davranış değişiklikleri. Bun.serve artık production'da HTML route'ları için sourcemap sunmuyor. Bun.serve() içindeki HTTP/3 deneysel ve henüz production için tasarlanmadı. 1.3.5'ten beri varsayılan trusted-dependencies listesi yalnızca npm registry paketlerini kapsıyor; dolayısıyla file:, link:, git: veya github: bağımlılıklarının lifecycle script'lerini çalıştırabilmesi için kendi trustedDependencies girdisi gerekiyor.
• Kendi yükünüz altında bellek kullanımı. %13 ile %48 arasındaki rakam, Bun 1.4'ü kendi benchmark'larında Bun 1.3 ile karşılaştırıyor; sizin trafiğinizle değil ve Node ile de değil.

Benim yorumum#

Production'da kullanılan bir runtime dil değiştirdi ve Claude Code tarafında neredeyse kimse fark etmedi. Bu işe yaradı, çünkü projenin dili umursamayan bir spesifikasyonu ve onu sahada pişirecek gerçek bir tüketicisi vardı. Kendi stack'imdeki Fastify ve Express servisleri için bellek rakamları denemeye değer. Doğru ilk adım, nginx arkasında rollback yolu olan tek bir canary instance, eksiksiz bir contract suite koşusu ve bir haftalık bellek grafikleri. Test sayıları nereye bakmanız gerektiğini söyler. Güvenli olduğunu söylemez.