Debug modunda self-hosted x86 backend varsayılan olarak ayarlandı

• Artık x86_64 hedeflerinde, Zig’in self-hosted x86 backend’i debug modunda varsayılan olarak uygulanıyor
• Mevcut LLVM tabanlı yaklaşıma kıyasla daha fazla davranış testini geçiyor ve daha hızlı derleme sağlıyor
• Self-hosted backend’in devreye alınmasıyla Zig’in derleme süreleri önemli ölçüde kısalıyor ve bazı işlerin verimliliği artıyor
• Son dönemde iyileştirilen build sistemi, BSD ailesi işletim sistemi desteğinin genişletilmesi, UBSan runtime geliştirmeleri gibi birçok alanda güçlendirmeler yapılıyor
• Standart kütüphane ve kendi araçlarının optimizasyonuyla Zig’in kendine özgü rekabet gücü öne çıkarılıyor

---

En son önemli gelişmelerin özeti

8 Haziran 2025 – Self-hosted x86 backend, debug modunda varsayılan hale geldi

• x86_64 hedeflerinde artık varsayılan olarak Zig’in self-hosted x86 backend’i kullanılıyor
  • Önceden LLVM kullanılarak bitcode’dan object file’a dönüştürme yapılıyordu
  • Windows tarafında COFF linker çalışması daha fazla gerektiği için bu değişiklik ertelenmiş durumda
• Zig’in x86 backend’i 1.987 davranış testini geçerek LLVM backend’ine (1.980) göre daha güçlü bir kararlılık sergiliyor
  • Toplam test sayısı 2.084, ancak bazılarının LLVM’in kendi testleriyle çakışması nedeniyle self-hosted backend testlerinde ayrıca doğrulanıyor
• Zig’in kendi code generator’ünü geliştirmeye odaklanmasının temel nedeni, build hızında LLVM’i açık ara geride bırakmak
  • Benchmark sonuçlarına göre zig build-exe hello.zig -fllvm (LLVM kullanımı) için ortalama build süresi 918 ms iken, self-hosted backend 275 ms kaydediyor
  • Bellek kullanımı, CPU cycle sayısı, instruction sayısı, cache miss gibi tüm alanlarda büyük iyileşmeler görülebiliyor
  • Zig derleyicisinin kendisi gibi büyük projelerde de build süresi 75 saniyeden 20 saniyeye düşüyor
• İleride code generation’ın tamamen paralelleştirilmesi, linker yeteneklerinin güçlendirilmesi ve aarch64 backend geliştirmesi planlanıyor
  • Yeni Legalize pass’in devreye alınmasıyla aarch64 çalışmaları da hızlanacak
• En güncel değişiklikler, Zig’in master branch’inin en yeni build’i üzerinden doğrudan deneyimlenebilir

6 Haziran 2025 – Build sistemi tanıtım videosu

• Zig build sistemine yeni başlayanlar için bir YouTube rehber videosu yayımlandı
  • Zig modülleri ve paketleri oluşturma, bunları başka projelerde import etme gibi konular anlatılıyor
  • Build sistemiyle ilgili ek videoların da seri halinde gelmesi planlanıyor

20 Mayıs 2025 – FreeBSD ve NetBSD hedef desteği güçlendirildi

• Pull Request #23835 ve #23913’ün birleştirilmesiyle zig cc ve zig build üzerinden FreeBSD 14.0.0+ ve NetBSD 10.1+ hedefleri için binary build almak mümkün hale geldi
  • Daha önce glibc’de kullanılan libc ve ilgili kütüphane bilgilerini çıkarma stratejisi BSD ailesine de genişletildi
  • Üretilen abilists dosyaları Zig ile birlikte dağıtılıyor; böylece cross-compilation sırasında her libc kütüphanesine doğru eşleşen stub kütüphaneler üretilebiliyor
  • Sistem ve libc header’ları da en güncel OS sürümü temel alınarak birlikte sağlanıyor
  • OpenBSD, Dragonfly BSD, SerenityOS, Android ve Fuchsia da destek hedefleri arasında yer alıyor

9 Nisan 2025 – Resmi Zig sitesi artık bağımsız çalışabilen Zine ile build ediliyor

• Resmi Zig web sitesinin yapısı artık bağımsız çalışan bir Zine ile build edilecek şekilde değiştirildi
  • Önceki build script’i tek bir executable dosyaya dönüştürüldü
  • Bunun doğrudan denenmesi için iyi bir zaman olduğu belirtiliyor

Sürüm ve özellik iyileştirmeleri

• 0.14.0 sürümü yakında yayımlanacak ve dikkat çekici birçok iyileştirme şimdiden uygulanmış durumda
• C interop ve UBSan (Undefined Behavior Sanitizer) runtime iyileştirmeleri sayesinde, daha önce belirsiz olan SIGILL hataları artık daha somut ve kullanışlı hata mesajlarıyla değiştirildi
  • Örn. signed integer overflow’un oluştuğu yer ve nedeni açıkça gösterilerek debug verimliliği büyük ölçüde artırılıyor
• UBSan tarafında kalan sınırlamalar:
  • C++ vptr ile ilgili dinamik tür ve yaşam döngüsü denetimleri desteklenmiyor
  • assume_aligned, __nonnull gibi özniteliklerde doğru konum gösterimi henüz tamamlanmış değil

7 Şubat 2025 – Debug allocator ve SmpAllocator yenilikleri

• Debug allocator yeniden tasarlanarak runtime page size farkındalığı ve çeşitli optimizasyonlar eklendi
  • Memory map oluşturmanın azaltılması, gereksiz 0xaa/0x00 memset tekrarlarının kaldırılması, arama ve trie veri yapılarının çıkarılması gibi iyileştirmeler yapıldı
  • Metadata’nın sayfa içine inline olarak saklanması sayesinde compile error/doğrulama işlemleri daha kolay uygulanabiliyor
  • Mevcut C tabanlı malloc’a kıyasla okunabilirlik ve bakım kolaylığı açısından üstünlük sağlanıyor
• Eşzamanlı ortamlara uygun optimize edilmiş SmpAllocator ile multi-thread senaryolarda bellek tahsis verimliliği en üst düzeye çıkarıldı
  • glibc ile yapılan performans benchmark’larında hız ve kaynak kullanımı avantajı somut olarak gösterildi
  • Sonuç olarak bunun, Zig kullanımının C ve libc’yi aşması açısından önemli bir dönüm noktası olduğu değerlendiriliyor

24 Ocak 2025 – Zig’e özel debug ortamı sunuldu

• Jacob, Zig için bir LLDB (debugger) fork’u geliştirerek self-hosted backend’in debug desteğini güçlendirdi
  • LLDB fork’unun build edilmesi ve kullanımı için wiki belgeleri sağlanıyor
  • Zig’in self-hosted backend’ini kullanan geliştiriciler bu araçla daha gelişmiş bir debug ortamından yararlanabiliyor

Sonuç

• Zig, kendi altyapısı üzerinden performans artışı, build verimliliği ve debug kolaylığı hedefleri doğrultusunda yenilikçi değişiklikleri sürdürmeye devam ediyor
• Bağımsız algoritmalar, derleyici ve build/runtime araçlarının tamamında ayırt edici bir rekabet gücü oluşturuyor
• BSD gibi çeşitli platform desteği, kullanıcı odaklı mesaj iyileştirmeleri ve bellek modeli yenilikleriyle yazılım mühendisleri için pratikte faydalı ilerlemeler sunmayı sürdürüyor

[GN⁺]

Hacker News yorumu

• Bildiğim kadarıyla Zig, geliştirme deneyimini iyileştirmek için her gün çeşitli özellikler üzerinde çalışıyor. Örneğin yakın zamanda şu PR da vardı. Eskiden Zig için hot code swapping de geliştirme planları arasındaydı ve bu geliştirme hızına bakınca muhtemelen 1 yıl içinde x86_64 üzerinde bu özellik mümkün olacak gibi görünüyor. Kişisel olarak hissettiğim en büyük rahatsızlık comptime hızında. Derleme zamanında bir brainF** DSL çalıştırdığım bir deney olmuştu; gerçekten çok yavaştı (ama eğlenceli bir deneydi). Derleyicinin bu kısmının ne zaman iyileşeceğini merak ediyorum. Yeni backend’ler için de çok heyecanlıyım ve Zig için kendi URCL backend’imi de yapmak istiyorum 😉

  • comptime performansını iyileştirmek için ne yapılması gerektiğini zaten biliyoruz ve çok eskiden bununla ilgili bir branch de başlatmıştık. Ama bu, semantik analiz kodunu anlamlı ölçekte yeniden elden geçirmeyi gerektiriyor; yani önemli işlerden biri olsa da başka önceliklerle rekabet ediyor

  • Hot code swapping, oyun geliştirme alanında muazzam bir fark yaratabilecek bir özellik. Zig’de bunun yalnızca bir derleyici flag’iyle doğal biçimde desteklenecek olması bana çok etkileyici geliyor. Çünkü clang ile buna kalkışmak bile zor

  • URCL’ye derinlemesine bakmadım ama bu beni başka bir tavşan deliğine sürüklüyor. Minecraft için yapılmış bir IR’ın bir dilin gerçek derleme hedefi hâline geldiği gerçekten tuhaf bir senaryo oluşabilir mi diye düşündürüyor

  • Özel backend yazmanın kolay olup olmadığını merak ediyorum. Henüz kendim denemedim ama AIR alıp bellek güvenliği raporu üreten bir backend deneyi yapmak istiyorum (örneğin tanımsız değer kullanımı, stack pointer escape, use-after-free, double free, alias xor mut vb. denetimleri yapan bir yapı)

  • comptime’ın gerçekten bu kadar yavaş olmasının sorun olup olmadığını merak ediyorum. Ben bir JSON-RPC kütüphanesi yazıyorum ve derleme zamanında comptime’ı yoğun biçimde kullanarak JSON’u keyfi fonksiyonlara dağıtıyorum. Zig’in güçlü statik tipleri yüzünden çalışma zamanında keyfi parametreleri olan bir fonksiyona dinamik dağıtım yapmak mümkün değil; bu yüzden derleme zamanında fonksiyon tipi eşlemeleri üretmek zorunda kaldım. Ama bu durumda her fonksiyon için comptime edilmiş kod kopyalanıyor gibi göründüğünden binary boyutunun büyümesinden endişeleniyorum

• Sadece bu noktaya gelmiş olmak bile başlı başına müthiş bir başarı. Devlog’da da söylendiği gibi, sonrası daha da heyecan verici görünüyor. Derleyicinin derleme sırasında binary’nin yalnızca gerekli kısımlarını değiştirmesi fikri hem taze hem de radikal geliyor ve Zig projesi sayesinde artık ulaşılabilir bir hedef oldu. Önümüzde çok ilginç bir dönem var

• Zig derleyicisi gibi büyük projelerde derleme süresinin 75 saniyeden 20 saniyeye düştüğünden bahsediliyor.
  Bunun daha ne kadar iyileşebileceğini gerçekten çok merak ediyorum. Zig geliştiricileri bana çok zeki insanlar gibi geliyor.
  Paket yönetiminin nasıl olduğunu da merak ediyorum. Bir ara QuickJS + SDL3 uygulamasını Zig ile yapmayı denemiştim ama C++ karmaşıklığı ağır basınca sonunda Rust’a geçmiştim. Zig ile de tekrar denemek istiyorum

  • Zig’in paket yönetimi Rust’a kıyasla biraz daha manuel. CLI üzerinden paket URL’sini doğrudan alıyorsun ve build script içinde modülü import ediyorsun. Bunun avantajı, keyfi arşivleri de bağımlılık paketi olarak kolayca kullanabilmen ve Zig için hazırlanmış birçok C kütüphanesi paketinin aslında dokunulmamış release tarball’larını build script’ten doğrudan bağlaması. Yalnız yeni başlayanlar için biraz karmaşık olabilir
    SDL3 için native Zig wrapper olan https://github.com/Gota7/zig-sdl3 ile, daha basitçe C kütüphanesini/API’sini Zig tarafına taşıyan https://github.com/castholm/SDL olmak üzere iki seçenek var
    QuickJS ise yalnızca C API’yi destekliyor https://github.com/allyourcodebase/quickjs-ng
    Zig, C paketlerini doğrudan kullanmayı çok kolaylaştırıyor ama tip sistemi katı olduğu için API kullanırken sık sık type cast gerekebiliyor

  • dmd D derleyicisi, kendisini debug build olarak yaklaşık 18.4 saniyede derleyebiliyor.
    Benim işlemcim çok eski bir AMD Athlon 64 X2 (4400+) ama o kadar hızlı çalışıyor ki hâlâ yükseltme bile yapmadım
    (ayrıntılı CPU bilgi listesi dahil)

  • Hızlı geliştirme döngüsü için Zig’i 20 saniyede build etmeye yönelik bir rehber olup olmadığını merak ediyorum. Daha önce Zig build etmeyi denediğimde birden fazla stage vardı (özellikle WASM bootstrap tarafı) ve gerçekten çok uzun sürmüştü

  • Zig’in LLVM kullanırken bile kendisini 75 saniyede derlemesi inanılmaz etkileyici

• Zig’den hiçbir şekilde aşırı şeyler talep etmek istemiyorum ve bunun açık kaynak olduğunu da çok iyi biliyorum, ama en çok ilgilendiğim şey gerçekçi bir 1.0 çıkış takvimi.
  Zig, düşük seviyeli bir dilden istediğim şeyleri neredeyse kusursuz biçimde barındırıyor ve artık sadece kararlı hâle gelmesini bekliyorum.
  Ayrıca Zig’in minimalist tasarım felsefesine içtenlikle hayranım

  • tigerbeetle gibi gerçek projeler genelde belirli bir release sürümünü sabitleyip kullanıyor, nightly sürümleri ise yalnızca deneysel amaçlarla kullanıyor diye biliyorum

• Tam bir acemi olarak Zig’in diğer dillere göre avantajlarının ne olduğunu merak ediyorum. Onu daha modern bir C gibi anlıyorum ama tam olarak hangi yönü “modern”?

  • Aklıma hemen gelen birkaç avantaj
    • Birden fazla ayrı araç ve dili birleştirmeyi gerektirmeyen entegre build sistemi
    • C’nin dizileri yerine (buffer overflow sorunları) uzunluğu açıkça bilinen slice’lar sunması
    • Varsayılan olarak null pointer’a izin vermeyen, gerektiğinde tipte açıkça görünen net optional tipi
    • enum, tagged union ve switch ifadesi için exhaustive kontrol zorunluluğu
    • Hata yönetimi açık ve net (biraz Rust tarzı). Bir fonksiyon hata döndürebiliyorsa çağıran taraf bunu görmezden gelemez. C’deki gibi dönüş değerini yok sayıp geçemezsin. Yalnız hata ve veriyi aynı anda döndürmek için standart sözdiziminin olmaması biraz eksik hissettiriyor
    • defer, errdefer bloklarıyla fonksiyon dönüşünde / hata oluştuğunda otomatik temizleme işlemleri yazabilme
    • Makrolar yerine comptime ile kod üretimi, tip yansıtma (@typeInfo vb.)
    • Bellek ayırıcıların çağıran tarafından yönetilmesi (belleğin nerede ve nasıl kullanılacağı üzerinde daha fazla kontrol)
    • GeneralPurposeAllocator kullanıldığında (özellikle başlangıç seviyesinde) bellek sızıntılarını izlemek daha kolay
      C’ye aşina değildim ve C’nin birçok mantıksız ve sezgisel olmayan yönü yüzünden düşük seviyeli programlamaya girmek bana hep zor gelmişti; Zig ise bana ilk kez sistem programlamasını eğlenceli ve ilgi çekici hissettiren dil oldu

• Zig’i 20 saniyede build etmeye dair bir rehber var mı merak ediyorum. Geliştirme döngüsünü hızlandırmak istiyorum ama stage1/2/3’ün hepsinin build süresi uzun olduğu için katkı yapmak kolay gelmemişti

• Zig’de zig init ile oluşturulan hello world’ün build çıktısı 9.3MB oluyorsa, -Doptimize=ReleaseSmall flag’i ile 7.6KB’ye düşebiliyor
  Tek bir flag ile 1000 kattan fazla fark oluşuyor

  • Aslında farkın %82’si debug bilgisinden geliyor
    -OReleaseSmall -fno-strip ile 580KB, -ODebug -fstrip ile 1.4MB da görülebiliyor
    Zig’in x86 backend’i ile Zig’e özel LLDB fork’u çok daha iyi bir debug deneyimi sunuyor
    Şu anda comptime mantığını debug ederken step step izlemek mümkün mü tam hatırlamıyorum ama yakın zamanda tartışılan bir konuydu

• Julia’nın performans avantajı elde etmek için Zig’i derleyici olarak değerlendirmesi mantıklı olabilir diye düşünüyorum. Julia geliştiricilerinin her sürümde performans gerilemesi kaygısı yaşamasını da hatırlıyorum

  • Julia fiilen LLVM’ye güçlü biçimde bağlı. Ekosistemin çeşitli parçaları LLVM intrinsics, autodiff (Enzyme), GPU derleme gibi bileşenlere dayanıyor.
    Derleyici tarafı yeniden hedeflenebilir hâle geliyor ama bu da şu anda aktif bir araştırma konusu.
    Gelecekte Zig’in dilin bazı bölümleri için alternatif derleyici olması gibi bir tablo hayal etmek mümkün

  • LLVM’nin bizzat Julia’nın public API’si olduğu görüşü de var. Gerçekten @code_llvm gibi doğrudan IR gösteren makrolar bulunuyor

  • Derleme süresini azaltma konusunda kesinlikle faydası olurdu ama Julia tarafında da hâlâ yapılacak çok şey var
    Derleme önbelleğini daha ince taneli hâle getirmek, invalidation’ı önlemeye yönelik araçlar, world splitting optimizasyonunun kaldırılması, derleyicide daha fazla multithreading kullanımı, belirli signature’lar için otomatik ön derleme, kodu lazy derleme / hot swap gibi özellikler bunlardan bazıları

• Bu Zig için muazzam bir ilerleme ve bence Rust’a kıyasla gelecekteki temel farklılaştırıcı unsurlardan biri olacak. Bu arada, performans analiz aracının render kodunun çoğunu ben yazdım; kodumun internette yaygın kullanılmasından mutluyum
  poop proje bağlantısı

  • Rust tarafında da Cranelift kullanan benzer bir girişim var
    rustc_codegen_cranelift bağlantısına bakılabilir

• Bunun tam olarak Zig’e async/await özelliğini geri getirebilmek için gereken önkoşullardan biri olduğunu düşünüyorum
  Zig’in async hakkındaki resmi SSS’si de bakmaya değer

  • Bu kısmı zaten toparlamış durumdayız ve önümüzdeki 2-3 ay içinde ilginç güncellemeler paylaşabiliriz. Neredeyse standart kütüphaneyi baştan yazıyormuş gibi tüm I/O tarafını yeniden elden geçiriyoruz

  • Linke göre async ya hiç geri gelmeyecek ya da en az 2028’e kadar ancak hayal olarak kalacak gibi görünüyor