Buz – En güncel Zig ve 1 saniyenin altındaki artımlı derlemeleri destekleyen bir Bun fork’u

• Buz, Bun’un Rust ile yeniden yazılmasından hemen önceki commit’ten yola çıkan, en güncel Zig tabanlı uyumlu bir alternatif olmayı hedefleyen erken aşama bir fork’tur
• JavaScriptCore vendor kaynakları dahil tüm derleme grafiği build.zige taşındı ve Zig’e küçük yamalar uygulanarak 1 saniyenin altında artımlı derleme sağlandı
• Rust sürümündeki Bun’un yeni özellik ve hata düzeltme testleri alındı, ancak başarısız olan çok sayıda test bulunduğundan upstream özellikleri ve JavaScriptCore değişikliklerinin takibi sürdürülmeli
• Kullanılmayan 11.000 satırdan fazla kod kaldırıldı ve bazı uygulamalar Zig standart kütüphanesi merkezli olacak şekilde modernleştirilirken çeşitli hatalar da düzeltildi
• Henüz prodüksiyonda kullanılamaz; LLM ile insan gözetimini birlikte kullanarak teknik borcu azalttıktan sonra LLM olmadan da bakımı kolay bir kod tabanı oluşturmak uzun vadeli hedeftir

---

Proje hedefi ve geliştirme durumu

• Buz, Bun’un Rust ile yeniden yazılmasından önceki son commit’i temel alan geliştirme aşamasındaki bir forktur
• Bun ile uyumlu bir alternatif olurken, mevcut olandan daha düzenli bir kod tabanı oluşturmaya odaklanır
• Geliştirme çok erken aşamada olduğu için prodüksiyonda kullanıma hazır değildir
• Benzer Zig tabanlı bir Bun projesi Ziggit’te zaten paylaşılmışken, geliştirme çalışmalarının gereksiz yere yinelenmesini önlemek amacıyla Buz kamuya açıldı
  • Yayınlandığı sırada söz konusu proje henüz incelenmemişti

En güncel Zig’e port ve artımlı derleme

• Bun, mevcut upstream Zig’e port edildi ve artımlı yeniden derleme için Zig’e küçük yamalar uygulandı
• JavaScriptCore’un vendor kaynakları dahil tüm derleme grafiği build.zig içinde birleştirildi
• Bu yapılandırmayla artımlı derleme süresi 1 saniyenin altına indi ve geliştirme döngüsü hızlandı
• Proje, artımlı derleme yamaları uygulanmış Zig master submodule’ünü içerir
• O dönemde upstream Zig commit’i 2b1c663 ile de sorunsuz derlenebiliyordu

Uyumluluk testleri ve upstream takibi

• Rust sürümündeki Bun’a eklenen testler alındı; bunların arasında yeni özellikler ve hata düzeltmelerini doğrulayan çok sayıda test de var
• Hâlâ geçemeyen çok sayıda test bulunduğundan Bun upstream’ini yakından takip etmeye devam etmek gerekiyor
• Özellik uyumluluğunu korurken kodu düzenleme ve teknik borcu azaltma çalışmaları da paralel ilerliyor
• JavaScriptCore değişikliklerinin de sürekli takip edilmesi gerekiyor

Kod tabanını sadeleştirme ve modernizasyon

• Bun’da hiç kullanılmayan 11.000 satırdan fazla kod kaldırıldı
• Kodun bir bölümü yeniden yazılıp modernleştirilirken Zig standart kütüphanesinin kullanımı artırıldı
• Sadeleştirme ve modernizasyon sürecinde çeşitli hatalar da düzeltildi
• Mevcut Bun kod tabanı yaklaşık 600 bin satır büyüklüğünde ve düzenli bir duruma ulaşmak için epey alt sistemin yeniden yazılması gerektiği düşünülüyor

LLM kullanımı ve katkı politikası

• Karmaşık mevcut kodu düzenlemek için LLM’den kapsamlı biçimde yararlanılırken, buna insan gözetimi ve daha iyi geliştirme pratikleri eşlik edecek
• Kod tabanının yeterince düzenli olduğuna karar verilene kadar insanlar tarafından yazılmış katkılar kabul edilmeyecek
• Teknik borcu azaltma ve Zig’de deyimsel kod yazımına öncelik verilirken, birkaç hafta ya da ay içinde Rust Bun 1.4.0 ile uyumlu bir alternatif olabilecek bir kod tabanı hedefleniyor
• Sol veya Fable kullanabilen geliştiricilerden destek isteniyor
• Uzun vadede amaç, LLM yardımı olmadan da bakımı kolay bir kod tabanı kurmak ve geliştirme sürecinde Zig yetkinliğini artırmak

[GN⁺]

Hacker News yorumları

• Bu fork’taki en ilginç gerçek, Bun’un aslında çok daha önce hızlı derlenebileceğini kanıtlamış olması
  Zig’in artımlı derlemesi henüz aarch64’ü desteklemiyor ve ikili yama da yalnızca Linux bağlayıcısında mümkün, ama ana platform desteği sadece zaman meselesi gibi görünüyor
  • Derleme hızını artırmak için Zig derleyicisini fork etmeleri etrafındaki yaygarayı düşününce, bunun en üstteki yorum olmaması şaşırtıcı
    Tek kişilik bir ekibin 1 saniyelik derleme elde etmiş olması, yavaş derlemelerin özensiz geliştirme pratiklerinin sonucu olduğunu ve forka harcanan zamanın tamamen yanlış bir kaynak dağılımı olduğunu gösteriyor
• LLM’in bozduğu kodu tekrar LLM ile toparlamak, sanki 2026’da teknolojinin zirvesine ulaşmışız gibi hissettiriyor
  • Şimdiye kadar da insanların bozduğu kodu yine insanlar toparlıyordu; mantıksal bir çelişki yok
  • LLM çıktısının kalitesi, onu yönlendiren kullanıcının becerisi kadar iyi oluyor
  • Yapay zekaya şüpheyle yaklaşıyorum ama kullanmaya açığım; eğer LLM gerçekten kendi çıktısını toparlayabiliyorsa bu oyunu değiştirebilir
  • Ben de aynı şeyi düşünmüştüm ama hemen ardından insanın kontrolü ele alacağından, teknik borcu azaltacağından ve daha idiomatik Zig kodu yazarak birkaç hafta ya da ay içinde Rust Bun 1.4.0’ın yerini alabilecek bir kod tabanı oluşturacağından söz ediyor
    Sonuçta daha fazla ya da daha iyi talimat vermekten bahsediyor gibi. Kod yapısı biraz da zevk meselesi gibi; dün de tek bir HTTP isteğini işlemek için dört arka uç sürecinin gerektiğinde ısrar eden biriyle absürt bir konuşma yaptım
  • Baştan beri yön bu gibiydi. İnsanların okuyamadığı ya da anlayamadığı, yazılımı andıran bozuk LLM çıktıları kod haline geliyorsa, sonunda bütün kodlar makinelerin okuyup yazacağı şekilde üretilecektir
    İnsan müdahalesi dönemi en başından beri geçici bir aşamaydı diye düşünüyorum
• Bun’da tamamen ölü 11.000 satır kodun kaldırılması ve standart kütüphaneden daha fazla yararlanacak şekilde modernize edilirken tonla hatanın da düzeltilmesi şaşırtıcı
  Büyük projelerde bu yaygın bir şey mi, yoksa sadece benim mi haberim yok merak ediyorum
  • Toplam 600 bin satır olduğuna göre ölü kod yaklaşık %1,8 ediyor. Kod tabanı büyüdükçe bir kodun gerçekten kullanılmadığını anlamak için daha geniş bir alanı görmek gerekir; ayrıca zamanla birbirinden uzak değişiklikler de ölü kod üretebildiği için bu daha yaygındır
    Bunun if (false) { dead_code(); } gibi apaçık bir örnek mi, yoksa dinamik dispatch mümkün olsa da mantıken çağrılamayan bir kod mu olduğu belirsiz. İlkiyse %1,8 yüksek, ikincisiyse düşük bile olabilir; eski feature flag’lerin arkasında fiilen sonsuza dek çalışmayacak kod biriktiren çok proje var
    Basit yardımcılar veya üretilmiş kod gibi az miktarda ölü kod bırakılabilir, ama bazen kaldırılması zincirleme silme ve sadeleştirmelere yol açar
  • Önceki şirketimde 10 bin satırlık bir bileşeni 2 bin satıra indirdim ve ana hataların hepsini düzelttim
    Teknik olarak ölü kod değildi ama küçük bir yanlış soyutlamayı temizleyince arkasından başka temizlik fırsatları da açılıyor ve sonunda geriye sadece amaçlanan işi yapan yazılım kalıyor. Kod tabanları zamanla şişer; bu yüzden Bun ölçeğinde yalnızca 11.000 satır bulunmuş olması daha şaşırtıcı
  • Zig derleyicisi tembel derleme yaptığı için, derlenmiş hiçbir fonksiyondan çağrılmayan ölü fonksiyonları tespit etmiyor
  • Bun’un geliştirme tarzı düşünülünce beklediğimden az; kod tabanında çok daha fazlası kalmış olabilir
  • Büyük bir kod tabanında bu kadar ölü koda şaşırılmasına şaşırıyorum. Normal boyuttaki yaklaşık 10 PR eder sadece
• Programlama kariyerinizde kaç yıl var da 11.000 satır ölü kodu bu kadar sıra dışı buluyorsunuz, merak ediyorum
  • 10 yılı aşkın deneyimim var. Kastettiğim şey hiçbir yerden çağrılmayan apaçık ölü koddu; başka projelerde de bunun bu kadar çok olup olmadığını merak ettim
• Ajan odaklı her kodlama projesinde, özellik geliştirme ile kod bakımı arasında bir tik-tak salınımı gördüm
  Tik aşamasında hızlıca özellik ekleyip doğru ama aşırı dağınık bir sürüm üretiyorsunuz; tak aşamasında ise ortaya çıkan şeyi sindirip toparlayarak performans, bakım yapılabilirlik ve değişikliklere kırılganlık tarafını iyileştiriyorsunuz
  Bazen bir günde vibe coding ile çalışan bir uygulama yapıp, ardından onu iskambilden yapılmış bir ev gibi çökmeyecek ve üstüne özellik eklenebilecek bir projeye dönüştürmek için bir hafta harcıyorum. Yapay zekadan önce de benzerdi ama uzman geliştiricilerin sistem için daha güçlü bir zihinsel modeli vardı ve daha yavaş çalıştıkları için geçiş bu kadar sert olmuyordu
  • Sonunda kodun içine girip mantığın her yere kopyalanmadığını ve gerçekten bakım yapılabilir olduğunu doğrulamak gerekiyor
    Kodlama modelleri, kapsüllemeyi bozan kestirmeleri seçmeye ya da kopyalanmaması gereken kodu çoğaltmaya çok yatkın
• Buna gösterişli performans programlama demek istiyorum. Performansı severim ve derleme süreleri de sıfıra yakın olmalı, ama artık azalan getiri bölgesine girildi ve şu anki darboğaz büyük ihtimalle derleme süresi değil
  • Bun geliştiricileri, artımlı derlemeden yararlanamadıkları durumda doğrudan uzun bekleme süreleri yaşadıkları için buna katılmazdı: https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...
    Büyük projelerde test çalıştırmak ya da anlam hatalarını kontrol etmek için her seferinde dakikalarca bekleyemezsiniz; bu yüzden derleme süresi açık bir darboğazdır
  • Bu tür projelerde hızlı derleme şart ve bakım işini kolaylaştıran önemli bir adım bence
• Kod kalitesini önemseyen birinin yönettiği bir Bun memnuniyet verici olurdu, ama Herkül işi gibi görünüyor
  • Herkül işinden çok, sonu gelmeyen bir Sisifos işine benziyor
• Tam tersine, yalnızca AI katkıları alan bir Zig fork’unu da görmek isterim
  Bunu yapay zekayı çok savunduğum için değil; daha çok kavramsal sanat ya da deney gibi, iki projenin nasıl farklı evrileceğini görmek eğlenceli olurdu
• Yakından ilgili olan Cruller da yeniden yazım öncesi Bun kod tabanını kullanıyor, ama sadece üretim amaçlı runtime kısmına odaklanıyor
  Bağlantı: https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
  HN tartışması: https://news.ycombinator.com/item?id=49017344
• Bun’un neden bu kadar ilgi gördüğünü anlamıyorum. Neden sadece Node + npm + Vitest + Vite ile devam edilmiyor merak ediyorum
  • Bun’un avantajlarını Node’a getirmeyi amaçlayan Nub projesi var; insanların neden Bun’u tercih ettiğini ve mevcut araçlardaki boşluğu da iyi gösterebilir
    https://nubjs.com
  • Asıl mesele tam da o liste. Bir sürü aracı birleştirmek yerine, gereken her işi yapan tek bir runtime kullanabiliyorsunuz
    Amaca özel araçları birleştirmekte sorun yok ama her şeyin kutudan çıktığı gibi çalışması çok kullanışlı. Bun bundler’ında runtime API de var; böylece varlıkları sunan aynı süreç, harici bir bundler ile koordinasyon kurabilir ya da statik dosyaları diske yazmadan doğrudan bellekte bundle alabilir
  • Dört ayrı aracı saymak zorunda olmanız bile mevcut durumun ne kadar kötü olduğunu gösteriyor
  • Artık npm kullanmaya devam etmek için bir neden olduğundan da emin değilim