Mitchell Hashimoto, Zig Software Foundation’a 300 bin dolar bağış taahhüt etti

• Mitchell Hashimoto ve eşi, Zig Software Foundation’a 300 bin dolar taahhüt ederek Zig’in bağımsız geliştirilmesini ve vakfın faaliyetlerini açık biçimde destekledi
• Bağış, 2 yıl boyunca yılda 150 bin dolar olarak ödenecek; ilk taksit şimdiden iletildi
• Hashimoto, 2019’dan beri Zig’i takip ediyordu; 2021’de kullanmaya başladı, 2022’den itibaren yazılar yazmayı ve derleyiciye katkı vermeyi sürdürdü
• 2023’te duyurduğu terminal projesi Ghostty de Zig ile yazıldı; şu anda kodlama zamanının büyük kısmı Zig’e ayrılıyor
• Zig’in kararlılık ve daha geniş sektör benimsemesi için hâlâ katetmesi gereken yol olsa da Hashimoto, onu güçlü bir topluluğa ve sürdürülebilir bir finansman modeline sahip bir proje olarak görüyor ve bağış yapılmasını öneriyor

---

300 bin dolarlık bağış taahhüdü

• Mitchell Hashimoto ve eşi, Zig Software Foundation’a 300 bin dolar bağışlamayı taahhüt etti
• Ödeme, 2 yıl boyunca her yıl 150 bin dolar olacak şekilde yapılandırıldı
  • İlk taksit şimdiden iletildi
• ZSF, ayrı bir duyuruda vakfın misyonunu ve fonların somut kullanım alanlarını ele alıyor

Hashimoto’nun Zig’i destekleme nedeni

• Hashimoto, 2019 civarından bu yana Zig projesini takip ediyordu ve 2021’de projeye dair beklentisini kamuoyuyla paylaştı
• 2021’in sonlarından itibaren Zig kullanmaya başladı; 2022’nin başından itibaren Zig ile ilgili yazılar yazmaya ve derleyiciye katkıda bulunmaya başladı
• Sonrasında da Zig deposuna düzinelerce kod katkısı yapmayı sürdürdü
• 2023’te duyurduğu terminal projesi Ghostty Zig ile yazıldı; Hashimoto şu anda kodlama zamanının çoğunu Zig’e ayırıyor

Zig ve ZSF hakkında değerlendirme

• Hashimoto, Zig’i değişim ve etki yaratabilecek bağımsız bir yazılım projesi olarak görüyor
• Zig, bir tutku projesi olarak başladı ve bugün de bu niteliğini koruyor; proje yönetimi ve topluluğu güçlü olarak değerlendiriliyor
• Finansman modelinin şeffaf ve sürdürülebilir; teknik açıdan ise iddialı ve yenilikçi olduğu kadar pratik ve gerçekçi olduğunu düşünüyor
• Kararlılık ve daha geniş sektör benimsemesi için hâlâ zamana ihtiyaç var, ancak buna ulaşacak yolun ve fırsatın net olduğunu değerlendiriyor
• ZSF fonlarının yaklaşık üçte biri bireysel bağışlardan geliyor; imkânı olanlara bağış yapmalarını öneriyor

[GN⁺]

Hacker News yorumları

• “Hayır işlerimiz normalde özel kalır, ancak geçmişim nedeniyle Zig’e açık desteğimin projeye gerçekten yardımcı olabileceğini düşündüğüm için bir istisna yapıyorum” cümlesi tuhaf biçimde içime dokundu
  Tam olarak ifade etmek zor, ama bunun içindeki temel zarafet övgüyü hak ediyor

  • Ben de benzer hissettim ama belki ters yönde
    Diğer hayır işlerinde açık desteğin faydası olmadığı mı kastediliyor? Öyleyse bu çalışmaların nasıl bir niteliği olduğunu merak ettim. Elbette kendi parasıyla yaptığı bağışta nihayetinde istediğini yapabilir, ama ifade biraz garip geldi
  • Para bağışlarken adını ortaya koymanın kendisi bir değer taşıyorsa gayet mantıklı
    Bu durumda bu açık destek, kendi bağış miktarından daha büyük ek katkılar çekebilir
  • İnandığı bir şeyi desteklediğini kısaca belirtip neden önemsediğini açıklaması bana tamamen doğal geliyor
  • Bunun açık destek olduğu için mi, yoksa hayır işlerinin genelde özel kalmasından mı kaynaklandığını merak ediyorum

• Zig Foundation’dan biri bunu görüyorsa bir iş ilanları panosu oluşturmasını şiddetle öneririm
  Belirli bir alana odaklı okur kitlesi olan yerlerde neredeyse bedava bir gelir kaynağı sayılır

  • Ben yaparım

• Aptalca bir soru olabilir ama web geliştiricisi olduğum için sistem/düşük seviye programlamaya genelde sadece merak düzeyinde bakıyorum
  Mümkün olan her durumda herkes bellek güvenli dillere geçilmesini söylüyor; Zig’de ise böyle bir garanti yok gibi görünüyor. Zig yeni bir dilse ana kullanım alanı yeni projeler olacaktır; o zaman bellek güvenli bir dille başlamak gerekmez mi diye düşünüyorum. Zig’in avantajı “C’den daha modern, Rust’tan daha basit” olmasıysa çekiciliğini anlıyorum; ama bellek güvenliğinin eksikliği bu avantajı zayıflatmaz mı?

  • Bellek güvenliği yararlı bir kavram ama ne her derde deva ne de ikili bir mesele
    Nihai hedef yalnızca güvenlik olsaydı JavaScript de yeterli olurdu. Güvenli Rust, bellek güvenliğini garanti ettiği için sistem programlamada büyük bir iyileştirme, ama her zaman nihai yanıt değil. Uygulamaya göre ödünleşimler var; kişisel olarak garantili güvenlikten çok güvenliği kolayca sağlayabilmenin daha önemli olduğunu düşünüyorum. C ve C++’ın sorunu, güvenli hale getirilmelerinin çok zor olmasıydı
  • Zig’in gerçekten parladığı alanlarda aynı kodu Rust ile yazarsanız çok fazla unsafe kullanmanız gerekir; bu da pratikte bellek güvenliği özelliklerini kapatmak anlamına gelebilir
    Zig’in gerçekten Rust’tan daha az güvenli olup olmadığını görmek için hâlâ zamana ihtiyaç var. Her iki durumda da programı güvenli yapmak için çok test yazmak gerekir; Rust tüm hataları sihirli biçimde ortadan kaldırmaz. Zig’de de debug modunda yeterince test yaparsanız çoğu bellek güvenliği hatasını yakalayabilirsiniz. Yine de bir web tarayıcısı gibi bir şey yapacak olsam Rust kullanırdım
  • C/C++ ile de çok hızlı ve çok güvenli kod yazılabilir
    Oyun sektörüne ya da yazılımın diske yazılıp dağıtılmak zorunda olduğu dönemlerdeki genel endüstriye bakmak yeterli. Bugünkü sorun, dil karmaşıklığının artması ve yazılım geliştiricilerin ortalama yetkinliğinin düşmesi. Google’ın Go’yu oluşturmasının nedeni de bir ölçüde bu sorunu çözmekti; Rust ise bellek güvenliğini tasarımının merkezine koyan başka bir dil. Rust’ın daha güvenli program yazmaya elverişli olmasının bir başka nedeni de C++’tan çok daha az karmaşık olması. Giderek karmaşıklaşıyor ama neyse ki Rust topluluğunda bellek güvenliği kavramı derinden yer etmiş durumda; dil karmaşıklaşsa bile bu avantaj ve geliştiricilerin alışkanlıkları sürecektir
    Zig de güvenliği önemsiyorsa iyi bir seçim. defer gibi sözdizimleriyle işleri basitleştiriyor ve geliştirme sırasında bellek güvenliği sorunlarını yakalamak için çeşitli çalıştırma hedefleri ve araçlar sunuyor. Bunu derleyicinin zorlamasıyla değil, geliştirme/ReleaseFast olmayan derlemelerde çalışma zamanında yakalama yoluyla yapıyor; yine de C/C++’a göre iyileştirilmiş bir biçim
  • Zig’in tamamını “bellek güvensiz” diye damgalamak konusunda emin değilim
    C’de olmayan oldukça zengin bellek güvenliği araçları ve denetimleri var. Güvenlik bir spektrum. C, C++’tan daha az güvenli; C++, Zig’den daha az güvenli; Zig, Rust’tan daha az güvenli; Rust, Java’dan daha az güvenli; Java da Python’dan daha az güvenli. Tanımsız davranış ve bellek bozulması hepsinde hâlâ mümkün; fark, bunun ne kadar kolay gerçekleştiğinde
  • Bellek güvenliği eksikliğinin Zig’in avantajlarını kısmen zayıflattığını düşünüyorum
    Ancak Zig henüz tamamlanmış bir dil değil, bu yüzden şimdiden kesin hüküm vermek zor. Zig’de de iyi bellek güvenliği özellikleri var; JavaScript ya da Rust düzeyinde değil ama C ile aynı da değil. Önceden kontrol ettiğimde serbest bırakıldıktan sonra kullanım büyük bir sorundu; bu çözülmezse Zig’in geleceği olmadığını düşünüyorum
    JavaScript gerçekten bellek güvenli bir dil, ama çalışma zamanı ve soyutlama düzeyi sistem programlamaya uygun değil. Sistem programlama için temelde bellek güvenli, ama kaçış yolları olan; derleyicilerin ve CPU’ların genel olarak hedeflediği sanal PDP-11’in bir seviye üzerinde sayılabilecek kadar düşük düzeyli bir soyutlama gerektiğini düşünüyorum. Programcının CPU yürütme modeline göre düşünmesine izin vermeli ama ayrıntılara gömülmesini engellemeli; C ile birlikte çalışabilirliği de çok iyi olmalı
    Rust’ın ilkini iyi başardığını düşünüyorum. Zayıf noktası ikincisi. Düşük seviyeli özellikleri var ama dil özellikleri karmaşıklığının yığınının altına gömülmüş durumda. Ayrıca tamamen güvenli bazı bellek yönetimi kalıplarına izin vermediği için ya çok sık unsafe kullanmanız gerekiyor ya da kodu problem alanına değil çözüm alanına uyacak şekilde eğip bükmeniz gerekiyor
    Zig’de ilk taraf zayıf. İyi özellikleri var ama büyük boşlukları da var. Buna karşılık ikinci tarafta oldukça güçlü. Dilediğim yön, Zig’in varsayılan bellek güvenliği sunması ama bunu Rust’tan çok daha esnek biçimde yapması ve düşük soyutlama ile C birlikte çalışabilirliği konusundaki avantajlarını koruması

• Kısa süre önce self-hostinge geçtiği haberini görünce, bağışları boşa harcamayacak özellikle verimli bir proje olduğu hissine kapıldım

  • Zig derleyicisinin self-hosting’e geçmesinden[1] mi, yoksa Zig web sitesinin self-hosting’e geçmesinden[2] mi bahsettiğini merak ediyorum. Muhtemelen ikincisidir
    [1] https://kristoff.it/blog/zig-self-hosted-now-what/
    [2] https://ziglang.org/news/migrate-to-self-hosting/

• “Hayatım, gerçekten sevdiğim bir programlama dili var, biraz konuşmak istiyorum.”
  “Ha?…”
  “Bu dili gerçekten, gerçekten çok seviyorum; biraz bağış yapmak istiyorum…”
  “……Yine başladı……”

  • Ya da şöyle de olabilir:
    “Güzel! Cirrus SF50 Vision’ımıza atlayıp Andrew Kelley’ye bizzat teslim etmeye gidelim.”

• Kesinlikle iyi haber, ama perspektif koymak gerekirse bu miktar derleyicilerle çalışan deneyimli bir geliştiricinin yıllık maaşının yaklaşık 0,75–1 kişilik kısmı kadar
  Tahminimce Microsoft yalnızca TypeScript’e her yıl bunun 10–20 katını harcıyor, C++/C# gibi alanlara ise çok daha fazlasını harcıyordur.

  • Bu kadar kazanan geliştiriciler de var; Microsoft veya Mozilla gibi yerlerde bu olasılık daha yüksek. Ama dünya genelindeki pazar ve küçük derleyici projeleri de hesaba katıldığında, yılda 150 bin dolardan az kazanan pek çok deneyimli derleyici geliştiricisi de olacaktır.
    Elbette geliştirici maliyeti maaştan ibaret değil. Yine de büyük teknoloji şirketlerinde ANSI standart derleyicilerle çalışan derleyici geliştiriciliğine benzer işlerde, daha özgür işlere kıyasla gerçek işin epey tatsız olduğunu ve bu yüzden içinde ciddi ölçüde tehlike tazminatı niteliği bulunduğunu hissettim.
  • Bu tür nispeten yeni ve yüksek potansiyelli bir projedeki rol, halihazırda Zig’e güvenen biri için oldukça cazip bir fırsat olabilir.
    Yeterli finansman varsa, ikinci bir iş yapmak ya da yalnızca geceleri/hafta sonları çalışmak zorunda kalmamayı sağlayan bir katalizör olur.

• Açıkçası Zig konusunda çok heyecanlıyım.
  Gereksiz fazlalıklardan arınmış ve çevik; gerçek kullanılabilirliği umursamayan bir fildişi kule insanının yaptığı bir dil değil. Haskell gibi doktoralı kişilerden oluşan bir ekip tarafından tasarlanmış da değil; yine de Rust veya Haskell gibi dillerdeki faydalı fikirlerden açıkça esinlenmiş görünüyor. Zig ile kod yazmak epey ilginç olacak gibi.

  • Ben de Zig konusunda benzer şekilde heyecanlıyım.
    Bellek güvenliği garantileri Rust kadar kapsamlı olmayabilir, ama bir gün Linux Kernel içinde Zig’i görebilmeyi isterim. Eski usul kernel C programcıları Rust’a kıyasla Zig’e daha kolay uyum sağlayabilir.
  • Bu görüşü dile getirince Zig tarafının hoşlanmayacağını biliyorum, ama vim veya VS Code gibi yerlerde zig fmt kapatılabilir olduğunda Zig’den yeniden umutlanacağım.
    Stil tercihinin zorunlu kılınması ağızda acı bir tat bırakıyor. Dili bir araç olarak kullanan geliştiricilere saygı duymayan bir tavır gibi geliyor. Topluluğa katılım ve farklı bakış açılarına açıklık konusunda daha derin bir sorun olduğunun işareti de olabilir; Zig’de gerçekten böyle bir sorun var gibi görünüyor[0].
    Kod tutarlılığına ihtiyaç duyan şirketler için linter çalıştırmak yeterli; hafta sonu projelerinde ise kendi stil tercihim dışında hiçbir şeyi umursamam. Bu, Zig’in yetişkinler için bir dil olup olmadığı meselesi. Nasıl olsa belirli bir şekilde kod yazmaya zorlanacaksam, üstüne ücretsiz bellek güvenliği de veren Rust’ı kullanmamam için bir neden yok.
    [0] https://github.com/ziglang/zig/issues/16270