Tip çözümlemesinin yeniden tasarımı ve dildeki değişiklikler

 (ziglang.org)
1 puan yazan GN⁺ 2026-03-12 | 1 yorum | WhatsApp'ta paylaş
  • Zig derleyicisindeki tip çözümleme (type resolution) mantığı baştan sona yeniden tasarlandı; iç yapı sadeleşti ve kullanıcıya da görünür iyileştirmeler sağlandı
  • Yeni tasarım, tip alanı analizini tembel (lazy) biçimde ele alarak, başlatılmamış tiplerin ayrıntılı yapısını gereksiz yere incelemiyor
  • Bağımlılık döngüsü (dependency loop) hata mesajları daha somut hale getirildi; böylece döngünün nedeni daha net anlaşılabiliyor
  • Artımlı derleme (incremental compilation) özelliğindeki aşırı analiz sorunu ve çok sayıda hata giderildi; bu da derleme hızını önemli ölçüde artırdı
  • Bu değişiklik, onlarca hata düzeltmesi ve küçük dil iyileştirmesi içererek Zig derleyicisinin performansını ve geliştirme deneyimini genel olarak güçlendiriyor

Tip çözümleme mantığının yeniden tasarımı

  • Yaklaşık 30 bin satırlık bir PR birleştirildi ve bununla Zig derleyicisinin tip çözümleme mantığı daha mantıklı ve sezgisel bir yapıyla yeniden yazıldı
    • Bu süreçte derleyicinin iç yapısı düzenlendi ve kullanıcılar da bundan doğrudan fayda sağladı
  • Derleyici artık tip alanı analizini tembel değerlendirme ile yapıyor; bu sayede başlatılmamış tiplerin ayrıntılı yapısını gereksiz yere taramıyor
    • Örnek kodda, @compileError alanı içeren bir struct yalnızca namespace olarak kullanıldığında, önceden derleme hatası oluşurken artık sorunsuz derleniyor
    • Bu, std.Io.Writer gibi namespace tipi kullanımlarında gereksiz kod bağımlılıklarını önlüyor

Bağımlılık döngüsü hata mesajlarında iyileştirme

  • Önceden bağımlılık döngüsü hata mesajları belirsizdi; artık döngünün nedeni ve konumu açık biçimde gösteriliyor
    • Örnek kodda Foo ve Bar struct'ları birbirine referans verdiğinde, hata mesajı her tipin bağımlılık konumunu ayrıntılı biçimde işaret ediyor
    • Mesajda döngü uzunluğu, her alan bildiriminin konumu ve hizalama sorgusunun konumu gibi bilgiler yer alıyor
  • Karmaşık döngülerde bile yeterli bilgi sunularak sorunun kaynağı kolayca anlaşılabiliyor

Artımlı derleme performansında artış

  • Bu değişiklikle birlikte artımlı derleme özelliğindeki çok sayıda hata düzeltildi
    • Özellikle “aşırı analiz (over-analysis)” sorunu çözülerek yalnızca değişen bölümlerin yeniden derlenmesi için optimizasyon yapıldı
    • Sonuç olarak birçok durumda derleme hızı önemli ölçüde arttı
  • Geliştiriciler, Zig 0.15.1 ve üzeri sürümlerde artımlı derlemeyi etkinleştirerek iyileştirilmiş geliştirme deneyimini yaşayabilir

Diğer iyileştirmeler

  • Bu PR, onlarca hata düzeltmesi, küçük dil değişikliği ve derleyici performansı iyileştirmesi içeriyor
    • Bunların çoğu ayrıntılı ya da özel durumlarla ilgili
  • Tüm değişikliklerin listesi Codeberg'deki PR #31403 sayfasında görülebilir
  • Yeni bir hata bulunursa issue bildirimi yapılması öneriliyor

Değişikliğin önemi

  • Tip çözümleme mantığının sadeleştirilmesi ve artımlı derleme optimizasyonu sayesinde Zig derleyicisinin kararlılığı ve verimliliği güçlendi
  • Geliştiriciler daha hızlı ve daha net geri bildirim alırken, büyük kod tabanlarında da üretkenlik artışı bekleyebilir

İlgili okumalar

1 yorum

 
GN⁺ 2026-03-12
Hacker News yorumları

  • Bu devlog’un yazarı benim
    Dil değişikliklerinin yol açtığı uyumluluk kırılmaları konusundaki kaygıları anlıyorum, ancak bu derleyici değişikliğinin büyük çaplı bir etki yaratacak düzeyde olmadığını belirtmek isterim
    Örneğin ZLS’yi yeni branch ile derlerken yalnızca .{} ifadesini .empty olarak değiştirmek gibi bir düzeltme gerekti. Bu da std.ArrayList’in varsayılan değerinin kaldırılmasından kaynaklanıyordu ve zaten 1 yıldır deprecated durumdaydı
    Ayrıca Awebo projesinde de tüm bağımlılık ağacında düzeltilmesi gereken yalnızca üç şey vardı — .empty değişikliği, comptime eklenmesi, orelse @alignOf(T) eklenmesi
    Bu tür düzeltmeler, Zig geliştiricilerinin çoğunun refleks olarak yapacağı kadar basit değişiklikler
    Bu PR’ın özü kırılma değil, bug düzeltmeleri ve artımlı derleme iyileştirmeleri

    • Değişikliği eleştirel karşılamış görünen yorumculardan biri bendim
      PR’ın kalitesi ve planlılığı çok yüksek diye düşünüyorum ve yazarın emeğini küçümsemek gibi bir niyetim kesinlikle yoktu
      Yalnızca bundan sonra daha fazla dipnot düşüp görüşlerimi daha dikkatli ifade etmem gerektiği dersini çıkardım
    • Zig’e doğrudan dahil değilim ama lib/std/multi_array_list.zig dosyasına eklenen yorumu görünce aklıma bir soru takıldı
      @alignOf(T) ifadesini MultiArrayList(T) tanımında kullanınca neden döngüsel bağımlılık oluştuğunu anlayamıyorum
      T, MultiArrayList’in kendisi olsa bile tamamen ayrı bir monomorfik tip değil mi? Sanırım bir şeyi gözden kaçırıyorum
      İlgili kod: bağlantı

  • Zig’i production ortamında kullananların deneyimlerini merak ediyorum
    Dil sık değişiyor; güncelleme döngüsü, yeniden yazım döngüsü nasıl işliyor, bağımlı paketler dil sürümünün gerisinde kalıyor mu, bunu da bilmek istiyorum
    Bun’ın Zig’i iyi kullandığını biliyorum ama başka örnekler de duymak isterim

    • Yaklaşık 250 bin LoC büyüklüğünde bir Zig derleyici kod tabanını sürdürüyorum (roc-lang/roc)
      Son 1–2 yılda dil ve standart kütüphanedeki değişiklikler büyük sorunlar olmadan ilerledi
      Eskiden yükseltmeler zahmetliydi ama şimdi daha çok “ufak bir rahatsızlık” gibi hissettiriyor
      Zig kullanma deneyimi sorulursa, bu konu artık neredeyse anılmayacak kadar istikrarlı
    • tigerbeetle ve sig olmak üzere iki production Zig kod tabanında çalıştım
      Bu tür büyük projeler yükseltmeleri etiketlenmiş sürümler üzerinden yapıyor ve göçü genelde birkaç gün ile birkaç hafta içinde tamamlıyor
      Bağımlılık da neredeyse hiç olmadığı için yükseltme yükü büyük olmuyor
    • Zig 0.15 oldukça stabil
      Yine de bazen küçük bir yazım hatası SIGBUS derleyici çökmesine yol açabiliyor, bu da debug etmeyi zorlaştırıyor
      .zig-cache 173GB’a kadar büyüyüp ARM VPS üzerinde sorun çıkarabiliyor
      lightpandayı 0.14’ten 0.15’e geçirirken sorun yaşamadım. 0.16 da muhtemelen büyük bir problem yaratmaz
      Ama bir kütüphane geliştiricisi olarak 0.16’daki hızlı değişim temposuna ayak uydurmak zor
      Şu anda yalnızca “dev” branch üzerinde deneysel olarak uyum sağlıyorum
    • Yaklaşık 20 bin LoC’lik Zig 0.16 kodunu DebugSafe modunda production’da çalıştırıyorum
      Node.js/TypeScript modüllerini Zig ile yeniden yazdım; sonuç 2 kat hız ve %70 daha az bellek kullanımı oldu
      Zig’in sqlite/JSON serileştirme desteği çok güçlüydü, bu da büyük avantaj sağladı
      Dezavantajı ise closure veya vtable sözdiziminin olmaması nedeniyle kod katmanlarını ayırmanın zor olması
      Arcs ve bumper allocator kullanarak bellek güvenliğini sağladım; DebugSafe modunda çalıştırmaya devam etmeyi planlıyorum
      ReleaseFast’e geçince %25 hız artışı gördüm ama güvenliği kaybedecek kadar büyük bir kazanç değil
    • C++’ın sonsuz geri uyumluluk vaadinin aslında dilin gelişimini engelleyen bir hata olduğunu düşünüyorum
      Kod değiştirmek gerekse bile uzun vadede doğru yaklaşım bu

  • Zig ekibinin ortaya koyduğu işten etkilendim
    Zig ile yazılmış ghostty terminalini sık kullanıyorum ve oldukça stabil
    Ama kişisel olarak Rust’ı tercih ediyorum
    Rust “kapalı dünya” modeli, Zig ise “açık dünya” modeli benimsiyor
    Rust’ta trait’lerin açıkça uygulanması gerekirken Zig’de tipin şekli (shape) uyuyorsa çalışıyor
    Bu sayede Zig çok güçlü bir metaprogramlama sunuyor ama tip çıkarımı belirsizleştiği için otomatik tamamlama, dokümantasyon ve LSP desteği zorlaşıyor

    • Somut bir örnek merak ettim
      Anlatımdan Go arayüzlerine benzer bir şey gibi geliyor ama bildiğim kadarıyla Zig’de buna doğrudan karşılık gelen bir kavram yok

  • kernel32’den Ntdll’e geçiş ilginçti
    Bu, Linux kullanıcı alanı API’sine de uygulanabilecek bir fikir
    Özellikle çekirdek-kullanıcı sınırında hata işleme biçimi benzer
    Ancak Linux’ta libc ile çekirdek sıkı biçimde iç içe olduğundan errno kullanımı zorunlu
    Windows’ta da bu örüntünün neden ortaya çıktığını merak ediyorum

    • errno ve GetLastError() örüntüsü thread öncesi dönemin kalıntısı
      Eskiden işbirlikçi zamanlama vardı ve global değişkenler güvenliydi; ama çok çekirdekli sistemler ve thread’ler ortaya çıkınca bu tehlikeli hale geldi
      Bunun alternatifi olarak thread local yapılar geldi

  • Tipleri namespace gibi kullanmak yerine, dile açık namespace eklemek daha iyi olmaz mı diye düşünüyorum

    • Zig dil minimalizmini hedefliyor
      Bir özellik birden çok yerde fayda sağlayıp optimize olabiliyorsa, onu ancak o zaman eklemeyi tercih ediyor
    • Aslında bu bir dolambaç değil, tasarımın zarafeti
      Zig’de @import bir dosyayı struct’a dönüştürüyor ve namespace’ler de sadece iç içe struct olarak ifade ediliyor
      Yani namespace aslında başka bir import türünden ibaret
      (Henüz yeterince kahve içmedim, o yüzden doğruluğu garanti edemem)

  • Dil değişikliği tartışmalarında sık gözden kaçan bir nokta var — bu da ekosistem etkisi
    Dil sık sık kırılıyorsa yalnızca uygulamalar değil, kütüphaneler, araçlar ve öğreticiler de sürekli buna ayak uydurmak zorunda kalıyor
    Sonuçta ekosistem, “bir kez yapılıp bırakılan” kütüphanelerden çok aktif biçimde sürdürülen projeler etrafında şekillenmeye başlıyor
    Bu, dil tasarımının erken aşamalarında makul bir takas olabilir ama uzun vadede ekosistemin büyümesini etkiler
    Diğer yeni diller bu değişim yorgunluğunu azaltmak için ciddi çaba harcıyor
    Zig’in yaklaşımının nasıl sonuç vereceğini izlemek ilginç olacak

    • Örnek olarak Blender eklenti ekosistemi verilebilir
      Blender API’yi sık sık kırıyor ama düzeltmelerin çoğu küçük oluyor
      Yine de birilerinin bunları düzeltmesi gerekiyor ve bakım kesilirse kullanıcıların kendisinin patch atması gerekebiliyor
      Ücretli eklentilerin sürdürülme ihtimali daha yüksek ama bu da garanti değil
    • Yine de Zig’in buna değdiğini düşünüyorum
      Bakımı yapılmayan kütüphaneler zaten kötü kod demektir
      Zig’i eleştirmek yerine başka dilleri (C3 vb.) pazarlamayı bırakın

  • Zig’in PR’ında geçen “Chromium, boringssl, Firefox, Rust advapi32.dll içindeki SystemFunction036’yı çağırıyor” ifadesi doğru değil
    Bunlar zaten ProcessPrng kullanıyor ve Windows 10 sonrasında bu çağrı başarısız olmuyor
    İlgili dayanak Microsoft whitepaper içinde yer alıyor
    RNG isteğinin asla başarısız olmaması için tasarlanmış; başarısız olursa süreç doğrudan sonlandırılıyor
    Yani yüksek kaliteli rastgelelik garantisi için hata kodu döndürülmüyor

    • (Bu, aynı sayfadaki başka bir devlog’a verilmiş bir yanıttır)

  • Zig’in dil semantiği yüzeyde basit görünüyor ama etkileşimleri incelikli
    Bu yüzden zamanla C++ template kuralları gibi karmaşık köşe durumları üretmesinden endişe ediyorum

  • 30 bin satırlık bir PR muazzam bir başarı
    Ama dil semantiğini değiştirmek son derece önemli bir iş, o yüzden şaşırdım
    Zig’in henüz 1.0 öncesinde olduğunu ve bu yüzden hızlı değiştiğini anlıyorum ama “bu branch’te semantiği değiştirdik” gibi gündelik bir ifade biraz afallatıcı geldi
    Bu çapta değişiklikler Zig’e özgü bir kültür mü, yoksa ben mi çağın gerisinde kaldım, merak ediyorum
    “modern Zig” ifadesi de dilin hızlı değişim temposu nedeniyle güldürdü

    • Üslubun gündelik olması, hafife alan bir tutum olduğu anlamına gelmez
      devlog bir pazarlama yazısı değil, daha çok içeriden kişilere yönelik bir kayıt niteliğinde; ayrıca Zig henüz 1.0 değil
      PR’da yeterli bağlam ve gerekçe var
      Zig’i seçtiğiniz anda belli ölçüde dil değişikliği riskini kabul etmiş oluyorsunuz
      Hatta şu aşamada temizce düzeltmek uzun vadede daha kazançlı
      (C’deki bit operatörü önceliği gibi düzeltilemeyen mirasları düşünün)
    • mlugg, Zig’in çekirdek katkıcılarından biri ve Zig Foundation üyesi
      Bu değişiklik döngüsel bağımlılıkları çözmek ve tip sistemini toparlamak için yapılıyor
      İlgili öneriler #3257 ve #15909 başlıklarında açıkça yer alıyor
      Bu değişiklikle Zig’in tip çözümlemesi DAG (yönlü çevrimsiz grafik) yapısı halinde düzenleniyor, böylece derleyici kararlılığı ciddi biçimde artıyor
      Zig, BDFN (Benevolent Dictator For Now) modeliyle yönetiliyor ve nihai karar yetkisi Andrew Kelley’de
      Ancak ekip kâr amacı gütmeyen bir yapı içinde çalışıyor ve kullanıcı güveni ile dil kalitesini en üstte tutuyor
      Kişisel olarak Matthew ile birlikte çalışmak benim için büyük bir onur
    • Muhtemelen bu yaklaşım, C dilinin karmaşık tarihini ters örnek olarak almaktan kaynaklanıyor olabilir
      Biçimsel olarak kusursuz görünse de pratikte kaotik bir dil olan C’yi hatırlatıyor bana