Yeniden Zig’e Dönmek - Zig → Rust → Zig

 (gracefulliberty.com)
4 puan yazan GN⁺ 22 시간 전 | 3 yorum | WhatsApp'ta paylaş
  • Zig, C’nin zorluklarını azaltmayı hedefleyen düşük seviyeli bir dil olarak başlayıp, açık bellek tahsisi ve gizli kontrol akışının olmaması gibi felsefeleriyle yeniden değerlendirilmeye değer bir dil haline geldi
  • Rust, Zig’in sık değişimleri ve olgunlaşmamış ekosisteminden kaçmak için pratik bir alternatifti; ancak FFI, çapraz derleme ve gizli tahsisler gibi noktalarda sınırlarını gösterdi
  • Zig’e geri dönme kararında yalnızca teknik nedenler değil, Rust projesine yönelik güven kaybı da etkili oldu; bunda yönetişim ve LLM ile üretilen kod politikası etrafındaki tartışmaların da payı vardı
  • 2026’daki Zig hâlâ kararsız ve Zig 0.17.0’ın derleme sistemini bozması bekleniyor; ancak dil hissiyatı 2020’den çok farklı değil ve paket yönetimi deneyimi iyileşti
  • Zig, Rust tarzı derleme zamanında bellek güvenliği sunmuyor; bunun yerine ReleaseSafe, test, fuzzing ve assertion felsefesiyle sadelik ile çalışma zamanı güvenliği arasında denge kurmayı seçiyor

Zig’e ilk çekildiğim nokta

  • Zig ile ilk kez 2020’de tanıştım ve o zamanlar derleme zamanında kod çalıştırma ile basit soyutlamalara sahip küçük, yeni bir dil gibi görünüyordu
  • C öğrenirken bilgisayarı doğrudan kontrol etme hissi güzeldi, ancak eski soyutlamalar ve yetersiz araçlar rahatsız ediciydi
  • Yeni ve kararsız olsa da Zig, C için bir yerine geçecek dil vaat ediyordu ve “bir sonraki dili” öğrenebilme fikri çekiciydi
  • Andrew Kelley’nin Software Should Be Perfect konuşması, programlama dilleri ve yazılıma bakış ölçütünü oluşturdu
    • Başarısız olabilen açık bellek tahsisi
    • Gizli kontrol akışının olmaması
    • Evrensel yeniden kullanılabilirlik
  • Zig ile oyuncak programlama dilleri, literate programming araçları ve web sunucuları yaparken, C’den daha rahat ama daha az riskli bir dil gibi hissettirdi

Rust’a geçme nedeni

  • Zig’de kod sık sık bozuluyordu ve öğrenci olduğum için projeleri en son dil sürümüne göre sürekli düzeltmeye zamanım yoktu
  • O dönemde anyzig yoktu; bu yüzden tek bir sistemde birden fazla Zig sürümünü kolayca kullanmak zordu
  • Bir projeye birkaç ay sonra geri döndüğümde, yeniden çalıştırabilmek için anlamadığım büyük bir refaktör yapmam gereken durumlar oluyordu
  • Ekosistem de henüz küçüktü
    • Yeni bir programcı olarak ihtiyaç duyduğum her şeyi kendim uygulayacak yetkinliğe sahip değildim
    • Kütüphane ve örnek sayısı azdı
    • Standart kütüphane sürekli değişiyordu
    • Temel dokümantasyon bile kararsızdı
  • Rust ise o sırada zaten yıllardır istikrar kazanmış ve güçlü bir ekosisteme sahip bir dildi
  • Rust öğrenmesi zordu ama bir kez öğrendikten sonra kod kararlı biçimde çalışıyordu ve bu kararlılık önemliydi
  • Hızlı ve düşük seviyeli bir dil olarak gereken ifade gücünü sağlıyor, aynı zamanda Zig’de yaşanan kararsızlığın maliyetini de azaltıyordu
  • Rust, daha az yerleşik denetime sahip diller kullanırken bile faydalı olan bir bellek modeli oluşturmama yardımcı oldu
  • panic olmayan kodda, gizli kontrol akışı ya da çöp toplayıcı olmadan yeniden kullanılabilir kod yazmak mümkündü
  • Yine de Rust, bellek tahsisini gizleme ve C ile çalışmayı zorlaştırma eğilimindeydi

Yeniden Zig’e baktıran memnuniyetsizlikler

  • Rust, istenen yeniden kullanılabilir programları yapmak için kusursuz bir dil değildi
    • FFI zordu
    • Çapraz derleme zahmetliydi
    • Gizli, başarısız olmayacakmış gibi ele alınan bellek tahsisleri yük oluşturuyordu
    • LLVM’ye bağlı olduğu için, C kadar çok platformu desteklemesi çok uzun sürebiliyor ya da mümkün olmayabiliyordu
  • Yönetişim de rahatsızlık veren bir nokta olarak kaldı
    • Rust Foundation’ın birçok büyük şirketten foundation members üyesi var
    • Dünyanın en büyük şirketleri her yıl yüz binlerce dolar sağladığında, bunun Rust’ın gelişim yönünü etkileyebileceği düşünülüyor
  • Açık kaynak topluluğunda LLM ile üretilen kodu kabul eden projelerin artması da sarsıcı bir etki yarattı
  • Birçok projede bakımcılar ve kullanıcılar LLM politikaları yazdı ya da talep etti
  • Zig ise projede LLM’leri tamamen yasakladı
  • Rust bir anket yaptı ve topluluğun genel hissiyatı LLM karşıtıydı, ancak hemen resmî bir politika oluşturmadı
  • Rust’ın politika önerisi, PR yorumlarında şu konuların anılmamasını öngören bir madde içeriyordu
    • LLM’lerin uzun vadeli toplumsal ve ekonomik etkileri
    • LLM’lerin çevresel etkisi
    • LLM çıktılarının telif hakkı statüsü
    • LLM kullanıcılarına yönelik ahlaki yargılar
  • Bu madde tepkilerin ardından kaldırıldı, ancak böyle bir maddenin var olmuş olması bile Rust projesine duyulan güveni azalttı
  • Politikanın kendisi çoğunlukla LLM’leri sınırlama ve slop’u azaltma üzerineydi; bu açıdan kabul edilebilir bulunuyor
  • Bu deneyim, yıllar sonra Zig’e yeniden ciddi biçimde bakma vesilesi oldu

2026’daki Zig

  • Zig hâlâ kararsız
  • İnternette bulunan Zig 0.16.0 örnekleriyle başlamak istedim, ancak bunlar şimdiden eski örneklerdi
  • Zig’de verimli çalışmak için standart kütüphane kaynak kodunun bir kopyasını el altında tutup ona alışmak en iyi yöntem gibi görünüyor
  • Zig 0.17.0’ın yakında çıkması ve tüm projelerin derleme sistemini bozması bekleniyor
  • Bakımcılar istikrara doğru ilerlemeye çalışıyor ve bu tür kırılmalar da bu sürecin bir parçası
  • Neyse ki dilin kendisi 2020’den beri çok fazla değişmedi
    • İçgüdülerin çoğu hâlâ işe yarıyordu
    • Kütüphanenin bazı kısımları yeniden işlense de kod okunması kolaydı
    • Bugünün Zig kodunun da 6 yıl sonra tanınabilir kalacağı düşünülüyor
  • Zig’de artık bir paket yöneticisi var
    • Önceden bağımlılık yönetimi için git submodule kullanıldığını hatırlıyorum
    • Yerleşik araç çok daha iyi
    • Projeler bağımlılıklarını git ve tarball ile tanımlayabiliyor
    • Vendor etmek kolay çalışıyor
  • Ekosistem hâlâ devasa değil, ama Zig’in hedefi de zaten devasa bir ekosistem değildi
  • Resmî bir paket kayıt sistemi yok ve bir başka NPM ya da crates.io’ya ihtiyaç olmadığı görüşü hâkim
  • Şu anki Zig’in iyi bir denge yakaladığı değerlendiriliyor

Bellek güvenliğine bakış

  • Zig, Rust ile aynı türden bellek güvenliği garantisi sunmuyor
  • Bu, sadelik için yapılmış bir ödünleşim ve Rust’ın affine type karmaşıklığının güvenlik kazancı kadar değerli olmadığı düşünülüyor
  • Yine de bu, Zig’in güvenlikten vazgeçtiği anlamına gelmiyor
  • Zig is safer than unsafe Rust bakış açısına göre, unsafe Rust kullanılması gereken durumlarda Zig daha iyi bir tercih olabilir
  • Zig’i daha güvenli hale getirmeye yönelik çalışmalar da sürüyor
    • Yaklaşım, unsafe kod bölgelerine değil release moduna odaklanıyor
    • Zig’in mevcut ReleaseSafe modu, assertion başarısızlığında çöküyor ve tüm belleği ilklendiriyor
    • Andrew Kelley, ReleaseSafe’e Fil-C benzeri bir şey katma yönüyle ilgileniyor
  • Bu yaklaşım, unsafeten kaçınılan Rust’ın derleme zamanındaki bellek güvenliğini sunmasa da, bazılarının söylediği gibi bir death spiral olarak görülmüyor
  • Bellek güvenliği bir spektrumdur ve her durum için en iyi tek bir yaklaşım yoktur
  • Zig’in yaklaşımı, ReleaseSafe’i çalışma zamanında mümkün olduğunca güvenli hale getirmek ve doğruluğu test ile fuzzing yoluyla doğrulamaktır
  • Denetlenmemiş illegal behavior bu süreçte bulunmalıdır; doğruluk kanıtlandıktan sonra diğer release modlarındaki ikili dosyaların güvenle dağıtılabileceği düşünülüyor
  • Bu yaklaşımın Rust modeline göre dezavantajları var, ancak Zig’in güçlü sadelik arayışı içinde bunun kesin olarak daha kötü olduğu düşünülmüyor
  • Eğer derleme zamanında bellek güvenliği, karmaşık bir tip sistemi ve uzun derleme sürelerinin maliyetine katlanmaya değecek kadar önemliyse, Rust seçilebilir
  • Zig’in bellek güvenliği modeli assertion felsefesine de uzanıyor
    • ReleaseFast’te assertion’ları devre dışı bırakmak yerine, testler aracılığıyla assertion’ın doğru olduğu ve ilgili yolun unreachable olduğu kanıtlanmış sayılıyor
    • Bu sayede Zig kodu optimize edebiliyor
    • İlgili yazı: your assertions are correct

Bundan sonra kullanım yönü

  • Standart kütüphane ve sürüm değişiklik kayıtlarını yakında tutarak Zig ile yazılım problemleriyle uğraşmaya hazırım
  • Düşük seviyeli ayrıntılarla uğraşmak istemediğimde tercih ettiğim betik dilini kullanmayı planlıyorum
  • Bundan sonraki yazılımlarda Zig’i temel araç olarak kullanmayı düşünüyorum
  • Zig’de kalmaya devam etmeme ihtimali de açık
    • Rust’ın kararlılığına veya tip sistemine ihtiyaç duyarsam Rust kullanabilirim
    • Zig’in yaklaşımına dair düşüncelerim tamamen değişebilir
    • Birden fazla dil bir arada var olabilir ve olmalıdır
  • Zig, yazılım kalitesini göz ardı etmeden kabullenerek kullanıcıya odaklanan bir yazılım vizyonunu temsil ediyor
  • İnsanlar güvenilir ve güçlü yazılımları hak ediyor; LLM çağında özenle hazırlanmış yazılımlar daha da nadirleşirken, insanların giderek kötüleşen slop’u kabullenmeye zorlandığı düşünülüyor

İlgili okumalar

3 yorum

 
clastneo 16 시간 전

Zig öğrenirken yeni bir sürümün çıkacağına dair bir şey görüp öğrenmeyi bıraktığım bir deneyim olmuştu.
Kararlı sürüm çıkarsa tekrar öğrenme listeme almaya değer olabilir ama şimdilik breaking change’ler çok fazla olduğu için el atmaya çekiniyorum.
 
click 19 시간 전

Zig dil spesifikasyonunu değiştirirken sürekli geriye dönük uyumluluğu bir kenara bırakıyor; böyle olunca en azından 1.0 çıkana kadar kritik sistemlerde kullanmanın zor olduğunu düşünüyorum.
ghostty’nin std.IO değişikliği yüzünden epey uğraştığı anlaşılıyor: issue
Başka bir dilden örnek vermek gerekirse, Java’da Future çıktıktan sonra JDBC API’si Future veya CompletableFuture döndürecek şekilde değiştirilmiş olsaydı, kesinlikle büyük bir ilerleme olurdu ama karşılığında muazzam bir karmaşa yaratırdı.
 
GN⁺ 22 시간 전
Lobste.rs yorumları

  • Bir gün Zig’i yeniden denemek istiyorum
    Gerçekten denemek istiyorum ama şimdiye kadar başka işlerden dolayı meşguldüm
    Zig’e en son dokunduğumda yaklaşık 3 saat içinde bir derleyici hatasıyla karşılaşmıştım ve epey aklımda kalmıştı. Adil olmak gerekirse, o hata o sırada en güncel branch’te zaten düzeltilmiş durumdaydı

  • “LLVM’e bağlı olduğu için C kadar çok platformu desteklemesi çok uzun sürer ya da hiçbir zaman mümkün olmaz” sözü bana şüpheli geliyor
    LLVM’in desteklemediği hangi platformu hedeflemek istediklerini ve Zig’in bu açıdan nasıl daha iyi olduğunu merak ediyorum
    Zig’in tier-4 C kodu ürettiğini, GCC’nin de bunu hppa, alpha, sh için derleyebildiğini mi söylüyorlar, bunu sormak isterim

    • Benim anladığım kadarıyla Zig, LLVM bağımlılığını azaltma çalışmasını aktif olarak yürütüyor; bu da gelecekte Zig derleyicisine yeni hedefler eklerken LLVM projesinin kendisine dokunmak gerekmeyebilir anlamına daha yakın
    • Şu anda bunun uygulama yöntemi C kodu üretimi
      Sorun şu ki Zig’in LLVM dışında resmi bir backend’i var, Rust ise LLVM kullanıyor
      Yazılımın yeniden kullanılabilirliğini en üst düzeye çıkarmayı amaçlayan bir sistem dili mümkün olduğunca geniş bir yerde çalışabilmeli; Zig gibi C’nin yerini almayı hedefliyorsa bu özellikle böyle
    • Belirsiz hatırladığıma göre, endişenin odağı platform desteğinden çok derleme süresi tarafına daha yakındı

  • ghostty’nin başarısını gördükten sonra Zig 1.0’a ulaştığında onu oyun geliştirme için kullanmayı planlıyorum
    Yine de yaptığım türde oyunlar için bu düzeyde performansa gerçekten ihtiyaç olup olmadığından pek emin değilim

  • “Zig güvenlikten vazgeçmiş değil ve unsafe Rust’tan daha güvenli. Zaten unsafe Rust kullanmak zorunda olduğunuz bir durumdaysanız Zig daha iyi olabilir” tarzı sözler oldukça yaygın ama her gördüğümde pek anlayamıyorum
    Özellikle yazarın güvenliğin bir spektrum olduğunu kabul etmesine rağmen, yerel unsafe bölgeler kullanmak yerine her şeyin sürekli unsafe olduğu bir dile geçmeyi önermesi tuhaf geliyor
    Soyut makine üzerinde akıl yürütmek biraz daha kolay olabilir ama bu takas bana ikna edici gelmiyor