Zig’in yaratıcısı Andrew Kelley ile röportaj

 (youtube.com)
2 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Zig, C’nin performansını ve kontrol gücünü korurken footgun’ları ve hata ayıklama zayıflıklarını azaltmayı, CPU ve belleği doğrudan gözeten bir sistem dili olmayı hedefliyor
  • Temel fark yaratan unsur toolchain; sistem bağımlılığı olmadan, hangi OS’te çalışırsa çalışsın, hangi OS’yi hedeflerse hedeflesin, her şeyi yalnızca zig build ile derlemeyi amaçlıyor
  • 1.0’ın gecikmesi, geriye dönük uyumluluk sözünü aceleyle vermemek için yapılmış bir tercih; 501(c)(3) statüsündeki kâr amacı gütmeyen yapısı sayesinde de uzun vadeli iyileştirmelere odaklanabiliyor
  • Zig Software Foundation, 2024’te 670 bin dolar gelir elde etti ve çeşitli sponsorluk yapıları kurdu; ayrıca CI’ın güvenilir çalışmasını önceleyerek GitHub’dan Codeberg’e geçti
  • Issue ve pull request’lerde no LLM, no AI politikası uygulanıyor; yapay zeka katkılarının inceleme süresine ve mentorluk kapasitesine zarar vererek eksi değer ürettiği düşünülüyor

Zig’in çıkış noktası ve dil tasarımı

  • Ortaya çıkış arka planı

    • Andrew Kelley, dijital ses iş istasyonu yapmak için sırasıyla JavaScript, Go, Rust ve C++ denediğini, ancak her birinin istediği kullanıcı deneyimini oluşturmakta belirli sınırları olduğunu düşündüğünü söylüyor
    • JavaScript’in tarayıcı içinde fazla yüksek seviyeli olduğunu ve bu yüzden bilgisayarın yeteneklerinden yeterince yararlanmayı zorlaştırdığını değerlendirdi
    • Go’nun C kütüphaneleriyle birlikte çalışabilirliğinin zayıf olduğunu; ayrıca ses işleme gibi belirli bir süre içinde tamamlanması gereken gerçek zamanlı işlerde garbage collector’ın glitch veya skip yaratabildiği için uygun olmadığını düşündü
    • Rust’ın 1.0 öncesi dönemde kurallarını karşılamasının zor olduğunu, küçük değişikliklerin bile derleme hataları zinciri yarattığını ve yazı tipi işleme tarafını bir ay boyunca ayarladıktan sonra bile ilerlemenin zorlaştığını hissetti
    • C++ başlangıçta üretken olsa da, küçük yazım hataları veya dikkatsizliklerin bellek bozulması hatalarına yol açıp haftalar süren hata ayıklama gerektirdiğini; ayrıca C++ derleyicisi ve C bağlayıcısıyla yazılan “C tarzı C++” yaklaşımında da footgun sorununun sürdüğünü düşünüyor
    • Zig’in çıkış noktası, toolchain’in izin verdiği sınırlar yerine bilgisayarın temelde yapabildiği şeyleri ölçüt alıp kullanıcı deneyiminden taviz vermemekti

  • Neden C’nin yerini alabileceğini düşünüyor

    • Zig’in, C’nin gücünden vazgeçmeden C’nin kusurlarını ve zayıflıklarını iyileştirdiği için C’den daha iyi olduğunu düşünüyor
    • C’nin yerini almaya çalışan diğer girişimler C’nin sahip olduğu bazı şeylerden vazgeçti; Zig ise C’nin yapabildiği her şeyi yaparken footgun’ları azaltıyor ve hata ayıklanabilirliği artırıyor
    • C’de signed integer’lar için yalnızca optimize edilmiş tamsayı davranışı, unsigned integer’lar içinse yalnızca wraparound anlamı varken; Zig’de hem signed hem unsigned için wraparound ya da overflow olmaması garantisi seçilebildiğinden, bunun C’den daha “C gibi” olduğunu söylüyor
    • Bir dilin C’nin yerini alabilmesi için işletim sistemi çekirdeğinden gömülü cihazlara, video oyunlarından WebAssembly’ye kadar her yerde yeniden kullanılabilir kod yazdırabilmesi gerektiğini; Zig C düzeyinde yetenek ve kararlılık sunduğunda, daha yüksek performanslı ve daha az hatalı olan seçeneğin tercih edileceğini düşünüyor

  • Rust’tan farkı

    • Rust ile Zig arasındaki temel fark tip sistemi
    • Rust’ta bir fonksiyon parametresinin clone desteği verip vermediği, hangi arayüzleri desteklediği, hangi tiplerin geçirilebildiği gibi kuralların bir meta dille tanımlanması gerekiyor
    • Zig’de böyle bir katman olmadan ya somut tipler geçiriliyor ya da C++ template’leri gibi çalışan jenerik tipler veriliyor
    • Buradaki ödünleşim, Rust kodunun tip sistemi tarafından daha fazla güvence sunması, Zig kodunun ise okunan kod açısından daha sade olması
    • Rust, C++’a benzer bir RAII tarzına yakın duruyor; nesnelerin başka nesnelere referans verdiği ve referans sayısı 0 olduğunda otomatik olarak yok edildiği bir yönelim daha doğal görülüyor
    • Zig’de ise allocator çok daha açık seçik; reference counting yapılabiliyor ama bunun kodunu açıkça yazmak gerekiyor
    • Zig’de uygulamaya göre uyarlanmış bellek tahsis yöntemleri sıkça kullanılıyor; örneğin arena allocator ile tahsisleri gruplayıp tek seferde bırakmak, genel amaçlı allocator’ı nesne yönelimli bir yaklaşımda kullanmak ya da belirli amaçlara göre hibrit yöntemler kurmak mümkün
    • CPU’nun ne yapmasını istediğini düşünüp onu doğrudan yaptıran kod yazma yaklaşımının, Rust’a kıyasla Zig’de daha doğal olduğu düşünülüyor

  • Öne çıkan özellik ve toolchain

    • Zig’in killer feature’ı toolchain
    • Sistem bağımlılığı olmayan bir yazılım paketi olarak, hangi işletim sisteminde çalışırsa çalışsın çalışıyor ve hangi işletim sistemi hedeflenirse hedeflensin kod derleyebiliyor
    • Bir projeye müdahil olmanın ne kadar zor olduğu; README’de çok sayıda sistem paketi kurulmasının gerekip gerekmediğine, işletim sistemine göre adımların değişip değişmediğine, ortamı hazırlamak için kaç komut çalıştırılması gerektiğine, Docker ya da özel donanım gerekip gerekmediğine bakılarak anlaşılabilir
    • En iyi ölçüt tek satır, tek bağımlılık, herkes için her zaman çalışır yaklaşımı; Zig projelerinin README’sindeki build adımı için yalnızca zig build yeterli olmalı

  • Dil kuralları ve IO arayüzleri

    • Kullanılmayan değişkenlerin derleme hatası sayılması kuralının, büyük ölçekli refactor süreçlerinde hataları yakalayarak zaman kazandırdığını; değişkeni göz ardı ettiğini belirten bir yorum eklemenin maliyetinin düşük olduğunu düşünüyor
    • ZLS ekibinin editör desteği sayesinde ayar açıldığında kullanılmayan değişkenler otomatik olarak discard edilebiliyor, yeniden kullanılınca da discard kaldırılabiliyor
    • Yeni IO reader / IO writer arayüzleri, görsel yükleme kütüphanesi ya da veri formatı serileştirme kodu gibi yeniden kullanılabilir kodu bir kez yazabilmek için oluşturulmuş bir soyutlama
    • Amaç, tüketilen veri için reader’ı, çıktı için writer’ı parametre olarak alıp bunu paket hâlinde ayırmak ve aynı mantığı birçok uygulamada kullanabilmek
    • Okuma ve yazma işlemleri soyutlama katmanının altında gerçekleştiğinde, derleyicinin mantığı kavrayıp optimize etmesi zorlaşabiliyor ve performans kaybı doğabiliyor
    • Arayüzün içine buffer ekleyen tasarımın, derleyicinin iyi kod üretmesini sağlarken yeniden kullanılabilirliği de koruyan en uygun denge olduğu düşünülüyor

Kullanım örnekleri, 1.0 ve LLVM sonrası yönelim

  • Gerçek kullanım örnekleri

    • Zig, bilgisayar üzerinde tam kontrol sahibi olmak, performans ve bellek kullanımını son sınırına kadar zorlamak ve ikna edici bir kullanıcı deneyimi oluşturmak istendiğinde kullanılacak bir dil olarak sunuluyor
    • Ghostty, Mitchell Hashimoto’nun geliştirdiği bir terminal emülatörü ve kod kalitesi, topluluk yönetimi ile fuzz testi açısından iyi bir proje olarak değerlendiriliyor
    • TigerBeetle, finansal işlem veritabanı; PostgreSQL gibi ilişkisel veritabanlarının üstüne OLTP koyma stratejisinden farklı olarak özel amaçlı bir veritabanı inşa etti ve bunun bu tür stratejilerden “bin kat daha hızlı” olduğu söyleniyor
    • TigerBeetle, çalışırken kullanacağı tüm belleği baştan ayırıp daha sonra dinamik tahsis yapmayarak gecikmeyi öngörülebilir ve tutarlı tutuyor
    • Bun, JavaScriptCore ve çeşitli C++ kütüphanelerini kullanan bir JavaScript motoru ve glue code kısmı Zig ile yazılmış
    • Bun’ın yakın zamanda Anthropic’e satıldığını bildiğini, bunun sonucunda da Zig’i yapay zeka amaçlı kullanmak isteyenlerin arttığını düşündüğünü söylüyor
    • Uber, Go kodunun bağımlı olduğu C kodunu birlikte cross-compile etmek için Zigcc’yi C derleyicisi olarak kullanıyor ve bunu ARM64 hedefli derlemelerde değerlendiriyor

  • 1.0’ın gecikme nedeni

    • Zig 10 yılı aşmış olmasına rağmen hâlâ 1.0’a ulaşmadı; ancak 1.0’ın özünde bir geriye dönük uyumluluk sözü olduğunu ve bunun her proje için farklı anlam taşıdığını düşünüyor
    • Karşılaştırma olarak, Go’nun 1.0’dan sonra dili uzun süre neredeyse hiç değiştirmediğini; Rust’ın ise 1.0’a görece erken ulaştığını ama edition’lar sayesinde geriye dönük uyumluluğu korurken dili epey değiştirebildiğini anlatıyor
    • Zig Software Foundation bir startup değil, 501(c)(3) statüsünde bir kâr amacı gütmeyen kuruluş; bu yüzden yatırımcı baskısı, satış ya da exit planı yok ve uzun vadeli iyileştirmeler için zamanı var
    • 1.0 yayımlandığında, aceleyle kilitlenmiş kötü kararlara mahkûm olmayan, “uzlaşmasız bir sevginin ürünü” olmasını istiyor
    • “worse is better” ifadesi için, bunun dilsel olarak zaten mantıklı olmadığını düşünüyor; Zig ise more with less yaklaşımını benimsiyor
    • Düşük karmaşıklıktaki comptime özelliğinden büyük fayda elde etmeyi ve tek bir bayrakla tamamen farklı işletim sistemi ve mimariler için derleme yapabilen bir toolchain hedefliyor
    • 1.0 geldikten sonra benimsenmenin hızla artacağından emin olsa da asıl hedefin önümüzdeki 50 yıl için bir dil inşa etmek olduğunu vurguluyor
    • Yaklaşan 0.16 sürümünde bu tercihlerin sonuçlarının görünmeye başlayacağını düşünüyor

  • LLVM’den uzaklaşma nedeni

    • LLVM’den uzaklaşma nedeni olarak, çekirdek ürün için çekirdek bir bağımlılıktan kaçınılması gerektiği düşüncesini gösteriyor
    • 10 kişilik rekabetçi arcade oyunu Killer Queen örneğinde, geliştiricinin fizik motoru için Unity kullanması nedeniyle fizik motorundaki küçük bir değişiklik ya da hata düzeltmesinin bile rekabetçi oyun hissini değiştirdiğini ve bu yüzden yeni Unity sürümüne geçemediklerini anlatıyor
    • Çekirdek ürün için böyle bir bağımlılık kurmanın hata olduğunu düşünüyor ve Zig’in de LLVM konusunda bunu düzeltme sürecinde olduğunu söylüyor
    • LLVM’i “bisikletin yardımcı tekerlekleri”ne benzetiyor; Zig’i 10 yılı aşkın süredir geliştirirken derleyici geliştirme konusunda çok daha fazla şey öğrendiklerini ve artık yardımcı tekerlekleri çıkarıp LLVM ile rekabet edebileceklerini düşünüyor
    • Kendi x86 backend’lerinde, milyonlarca satırlık büyük kod tabanlarında bile değişiklik sonrası 50 ms’nin altında yeni binary üretilebilen incremental compilation mümkün

  • İsim ve öğrenme yolu

    • Zig adı, “Zig programming language” aramasında sıfır sonuç veren kısa bir kelime ararken Python betiğiyle rastgele kelimeler üretmesi sırasında seçilmiş
    • Maskot iguanaya “ziguana” deniyor
    • Yeni başlayanlara özellikle Ziglings tavsiye ediliyor
    • Ziglings, neredeyse çalışan kodlara kasıtlı sorunlar yerleştirilmiş ve bozuk programları düzelterek yeni dil özelliklerinin öğrenildiği bir dizi alıştırmadan oluşuyor
    • C’den Zig’e geçiş özellikle akıcı; C’de yapılabilen her şey Zig’de de yapılabiliyor ve footgun sayısı daha az
    • C’de segmentation fault olduğunda genelde ekranda yalnızca “segmentation fault” yazıyor ve sonrası hata ayıklayıcı kullanma becerisine kalıyor; Zig’de ise kodun ilgili satırlarını işaret eden tam bir stack trace alınabiliyor
    • Zig’in ilk programlama dili olarak öğrenilip öğrenilmeyeceği kişiye göre değişir; ancak bilgisayarların nasıl çalıştığını öğrenmek isteyenler için CPU ve belleği öğreten iyi bir dil olarak görülüyor

Vakfın işletimi, yönetişim ve platform seçimi

  • Finansman ve sponsorluk yapısı

    • 2024 yılında Zig Software Foundation’ın toplam geliri 670 bin dolar
    • Gelir kaynakları bireysel sponsorlar ve çeşitli şirket bağışlarından oluşuyor; yapı, tek bir tarafın geliştirme yönünü dayatamayacağı şekilde kurulmuş
    • Belirli bir sponsor “bunu yap” diye talepte bulunursa bunu reddedebileceğini, o sponsor desteğini kesse bile hayatta kalabileceklerini düşünüyor
    • Sponsorlar ancak hata izleyiciye katılmak, pull request göndermek ve geliştirme kanallarındaki konuşmalara katılmak gibi herkesle aynı yollarla etki edebiliyor; ayrı bir gizli yüksek öncelikli kanal yok
    • Andrew Kelley’nin yıllık maaşı 154 bin dolar ve bunun, ilk yönetim kurulunda kâr amacı gütmeyen kuruluşun kurulduğu şehirdeki kıdemli yazılım mühendislerinin medyan maaşı temel alınarak belirlendiği belirtiliyor
    • Vakıfta 1 çalışan ve tam zamanlı ücret alan yaklaşık 5 yüklenici bulunuyor; bir önceki yılın gelirinin %91’i proje üzerinde çalışan yüklenicilere ödenmiş
    • Koşulsuz 100 milyon dolar teklif edilse kabul edebileceğini, ancak bunu büyümek için kullanmayıp bankaya koyarak 100 yıl boyunca bağış toplamak zorunda kalmamayı tercih edeceğini söylüyor
    • Şu anda 5 kişilik bir ekibi yönettiğini, 10 kişinin üzerinin ağır bir yük olabileceğini ve 100 kişilik bir organizasyonun yöneticisi olmayı düşünmediğini belirtiyor

  • 501(c)(3) ve şeffaflık

    • 501(c)(3) yapısının 501(c)(6)’dan farklı olduğu özellikle vurgulanıyor
    • 501(c)(6) bir iş dünyası birliği; Rust Foundation, Amazon, Netflix, Microsoft ve Meta gibi şirketlerin Rust’ın başarısında ortak çıkar görerek bağış yaptığı bir yapı olarak anılıyor
    • 501(c)(3) ise devlet nezdinde lobi faaliyetlerine izin vermiyor ve işletmelerin çıkarları için değil, yalnızca misyon bildirimi için var oluyor
    • Gelir ve giderleri ayrıntılı biçimde açıklayan blog yazıları bir zorunluluk değil, gönüllü şeffaflık; metrikler iyi olduğu için bunun güvene ve bağış toplamaya da yardımcı olduğu düşünülüyor

  • GitHub ve sosyal medyadan ayrılma nedenleri

    • Reddit ve Twitter’dan ayrılma nedeni, bu sitelerde paylaşım yapmanın Slashdot ya da Digg’de paylaşım yapmak gibi giderek daha az anlamlı hale gelmesi ve bir yazılım mühendisi olarak pazarlamaya ayırdığı zamanı en aza indirmek istemesi
    • Ne görüleceğini algoritmaların belirlediği veya trollerle etkileşime girilen sosyal medyaya kıyasla, yüz yüze etkinliklere ve meetup’lara odaklanmanın topluluğun büyümesi için daha iyi bir yatırım olduğunu düşünüyor
    • Zig’in ana deposunun 2025 sonlarında GitHub’dan Codeberg’e taşınma nedeni, GitHub’ın artık sürekli entegrasyon sonuçlarını düzgün sağlamaması ve “basitçe çalışmıyor” olması
    • Codeberg’e geçildikten sonra sürekli entegrasyon sunucusunun yeniden çalıştığı belirtiliyor
    • GitHub Sponsors’tan ayrılmak gelir kaynağı kaybı anlamına gelebileceği için zor bir karardı; ancak yazılım geliştirmek için CI’ın çalışmasının en yüksek öncelik olduğuna karar vermiş
    • GitHub’dan ayrıldıktan sonra mali açıdan “tamamen iyi durumda” olduklarını söylüyor
    • Zig, MIT lisanslı bir yazılım; bunu yazılım dünyasına yapılan koşulsuz bir bağış olarak görüyor ve sponsorluğu da koşulsuz bağış olarak değerlendiriyor
    • Codeberg’i seçme nedeni, GitHub’a özünde benzer olması sayesinde geçişin kolay olması ve Alman bir kâr amacı gütmeyen kuruluş olması
    • Kod forge’u projenin pazarlama aracı olarak görmüyor; insanların dili GitHub veya Codeberg üzerinden değil, duyurular, meetup’lar, YouTube videoları ve Zigday meetup grupları gibi yerlerden keşfettiğini düşünüyor

  • BDFL ve uzun vadeli yönetişim

    • Yazılım projeleri çoğu zaman hiyerarşik kontrol ile demokratik süreçlerden birini seçmek zorunda kalıyor ve birçok proje basitliği nedeniyle BDFL yaklaşımını benimsiyor
    • Kontrol tek kişideyse, o kişinin her şeyi anlaması ve proje için tutarlı bir vizyon taşıma sorumluluğunu üstlenmesi gerekiyor
    • Komitelerde farklı geçerli kullanım senaryoları ve vizyonlar çatışabiliyor; iki kullanım senaryosunu aynı anda karşılayan tek bir tasarım olmadığında uzlaşma daha kötü bir ürüne yol açabiliyor
    • Andrew Kelley ayrılsa bile, yazılım mühendisliği açısından ekip arkadaşlarının projeyi sürdürmeye yetecek kadar yetkin olduğunu düşünüyor
    • Organizasyon ve vakfın siyasi boyutu açısından ise hâlâ yapılacak işler olduğunu; paranın aktığı sistemlerin yozlaştığı görüşünden hareketle, paranın etkisine direnebilecek güçlü hiyerarşik liderliğin şu anda gerekli olduğunu savunuyor
    • Her şeyi tek bir güçlü liderin kontrol ettiği model sürdürülebilir değil; bu yüzden uzun vadeli sürdürülebilirlik için demokrasi gerekli, ancak zaman içinde paranın etkisiyle yozlaşmayacak şekilde tasarlamak asıl sorun

  • Başarı ölçütü

    • Zig’in başarısı bir açıdan bakıldığında zaten gerçekleşmiş durumda
    • Çeşitli gelir kaynakları sayesinde tek bir tarafa karşı mali açıdan bağımsız, memnun kalıp kullanmaya devam eden kullanıcıları var ve yılda yaklaşık iki kez sürüm çıkararak sürekli iyileşiyor
    • Başka bir açıdan ise daha fazla benimsenme istiyor ve başarının ölçülerinden biri Go ve Rust düzeyinde benimsenme
    • Ticari benimsenme, şirket bağışı alabilme açısından faydalı; ancak şirket bağışlarında da çeşitliliği korumaya dikkat etmek gerekiyor
    • Genel olarak faydalı bir şey yapıldığında bunun şirketler için de faydalı hale geldiğini ve insanların Zig’i yapay zekada kullanmasında bunun görüldüğünü düşünüyor

Yapay zeka politikası, geliştirme araçları ve programlamanın geleceği

  • LLM yok, yapay zeka katkısı yok politikası

    • Zig, issue ve pull request’ler için katı bir LLM yok, yapay zeka katkısı yok politikası uyguluyor
    • Yapay zeka katkılarının “değişmez biçimde çöp” olduğunu ve sadece değersiz olmakla kalmayıp inceleme süresini çalarak negatif değer ürettiğini düşünüyor
    • Şu anda açık 200’den fazla pull request var ve küçük geliştirme ekibiyle çok sayıdaki katkıcı arasında darboğaz inceleme süresi
    • Yapay zekayla üretilmiş katkılarda, birkaç inceleme turundan sonra katkıcının içeriği anlamadığı; inceleme geri bildirimini sohbete yapıştırıp dönen yanıtı kendi sözüymüş gibi cilaladığı bir örüntünün ortaya çıktığını düşünüyor
    • Kod incelemesi yapmanın ve katkı kabul etmenin temel nedeni mentorluk; amaç, katkıcıların ileride çekirdek ekip üyesine ya da daha değerli katkıcılara dönüşecek şekilde gelişmesini sağlamak
    • “contributor poker”, kısıtlı zamanı kime yatırarak onları daha iyi programcılar ve katkıcılar hâline getireceğine karar verme süreci
    • Yapay zeka kullanan kişilerin, her zaman yatırım değerinin düşük olduğu tek seferlik katkıcı kategorisine girdiğini; öğrenmediklerini ve çekirdek ekip üyesi olma ihtimallerinin bulunmadığını düşünüyor
    • Zig projesi aynı zamanda bir eğitim projesi ve öğrencilere rehberlik ile eğitim sağlamak misyonunun bir parçası
    • “Sadece iyi yapay zeka PR’larına izin verelim” denirse karar verecek birine ihtiyaç olur, ama toptan yasak uygulaması kolay bir politika
    • Yapay zeka üretimi olup olmadığını tespit etmenin her zaman kolay olmadığını ve bazılarının içeri sızmış olabileceğini kabul ediyor; ancak çok sayıda pull request incelendiğinde, geri bildirim alındığında verilen tepkilerin insan davranışı olmamasından ötürü bazı durumlarda bunun netleştiğini söylüyor

  • MIT lisansı ve yapay zeka eğitimi

    • Zig kod tabanı MIT lisansı altında ve yazılım lisanslarına aşina olmayan biri için fiilen public domain’e yakın
    • Neredeyse her amaç için kullanılabilir; kod kopyalanırken lisansın da yeniden üretilmesi gerekir, garanti yoktur ve sorunlar için Zig tarafı sorumlu tutulamaz
    • Büyük şirketlerin Zig kodunu yapay zeka eğitiminde kullanabilmesi ama Zig’e yapay zekanın katkıda bulunmasının yasak olması ironik
    • Zig’in dünyaya verdiği koşulsuz bir armağan olduğu fikrine güçlü biçimde bağlı olduğu için, yapay zeka eğitiminde kullanılmasını sorun etmiyor
    • LLM’lerin Python ya da JavaScript’e kıyasla Zig kodunda daha çok zorlanıp zorlanmadığını bizzat fazla denemediğini; ancak Mitchell Hashimoto’nun Ghostty’de yapay zekalı kodlamayı kapsamlı biçimde kullandığını söylüyor
    • Rocker ekran adlı bir kişinin, yapay zekanın Zig’de daha iyi çalışmasını sağlayan araçlar geliştirdiğini ve başarı gördüğünü belirtiyor

  • Vibe coding ve programlamanın geleceği

    • Bir projeyi uzun süre sürdürüp bu sırada beceri kazanmayı ve çözülen sorunları anlatan yazıları okumanın hayal gücünü tetiklediğini, insanı kendisinin neler yapabileceğini düşünmeye sevk ettiğini, bir şeyler öğrettiğini ve duygusal bağ kurdurduğunu söylüyor
    • “Claude’un şu sürümünü ya da OpenAI’ın bu sürümünü denedim ve şaşırtıcı derecede iyi sonuç verdi” türü vibe coding bloglarının ilham vermediğini düşünüyor
    • Yazılım kalite standardının “hatasız olması şaşırtıcı” değil, tavizsiz mükemmellik olması gerektiğini vurguluyor
    • Richard Feldman ile yaptığı özel bir görüşmede vibe coding’i denediğini ve teknolojinin kendisini temelde ilginç bulduğunu söylüyor
    • Ancak yaklaşık dört şirketin her şeyi merkezden kontrol etmesine ve model ile davranış üzerinde tam denetime sahip olmasına güçlü bir itiraz duyuyor
    • Kendi bilgisayarını ve elektriğini kullanarak kod yazma yönteminden, ağın ötesinde başkasının bilgisayarında kapalı kaynak programlamayı aylık abonelikle kullanma modeline geçmek istemediğini söylüyor
    • Bazı insanların ayda 300 dolar ödediğini ve bu teklifin kendisine çılgınlık gibi göründüğünü ifade ediyor
    • 10 ya da 20 yıl sonra da insanların kod yazmaya devam edeceğini; kodlamanın eğlenceli olduğunu ve en azından bir hobi olarak her zaman varlığını sürdüreceğini düşünüyor
    • Telefonlar ve bilgisayarlardaki en iyi uygulamaların, insanların boş zamanlarında hobi olarak yaptığı uygulamalar olduğunu; özgür ve açık kaynak yazılımın ve kendi cihazının sahibi olma arzusunun ortadan kalkmayacağını düşünüyor

  • Düzenleme ortamı ve refactoring araçları

    • Zig’in sözdizimi değişse bile kod düzenlemeye devam etmeyi sağlayacak dayanıklı bir çalışma ortamına ihtiyaç olduğunu söylüyor
    • tree-sitter ve language server gibi gelişmiş araçlar, kararlı bir sözdizimi ağacını ya da kararlı bir dili varsaydığı için dil bozulduğunda onlar da bozulabiliyor
    • Kişisel olarak Zig yazarken gelişmiş bir ortam yerine terminal ve Vim kullandığını, Vim’in değişime son derece iyi dayandığını söylüyor
    • ZLS, Zig language server’ın kısaltması; Zig için bir Language Server Protocol uygulaması ve Zig Software Foundation tarafından işletilmeyen üçüncü taraf bir proje
    • Zig web sitesi JetBrains ürünlerini önerse de Andrew Kelley, JetBrains ürünleri kapalı kaynak olduğu için bunları hiç kullanmadığını söylüyor
    • Geçmişte JetBrains ya da Eclipse’in sunduğu fonksiyon çıkarma, fonksiyon parametrelerini yeniden sıralama ve küresel ad değiştirme gibi yüksek seviye refactoring araçlarını olumlu bulduğunu belirtiyor
    • Uzun vadede, tür bilgisi ve diğer ipuçlarına dayanarak büyük değişiklikler yapabilen sorgu dili benzeri refactoring araçları istediğini söylüyor
    • Değişken adını değiştirmek gibi kapsamı net olan işler için, güvenilir bir araç işi yaptığında sonucu incelemeye gerek kalmadan commit oluşturabilecek kadar %100 emin olunabileceğini söylüyor
    • Aynı işi bir yapay zeka aracına yaptırdığında ise hâlâ kodu gözden geçirmek gerektiği için, bunun güvenilir refactoring araçlarından daha uzun sürdüğünü ve daha kötü bir tercih olduğunu düşünüyor

Kişisel motivasyon ve açık kaynak bakış açısı

  • Zig’i sürdürme motivasyonu ve zorluklar

    • Zig üzerindeki çalışma, bilgisayarları sevmekten ve bilgisayarların insanlara hizmet etmesini sağlama isteğinden doğuyor
    • Zig, harika bir programlama dili ve toolchain’in böyle bir sonuca yol açacağına dair iyimser bir armağan olarak ifade ediliyor
    • Kullanıcıları memnun etmek ve güçlü bir kullanıcı deneyimi oluşturmak büyük bir tatmin sağlıyor; iyi yazılım üretme hissi, bir müzisyenin sahnede performans sergilerken aldığı hisse benzetiliyor
    • Bir kâr amacı gütmeyen kuruluşu yürütmek için gereken vergi ve evrak işleri en zor kısım olarak gösteriliyor
    • Bunlar, yasal sorun yaşamadan faaliyet göstermek ve büyük bağışlar alabilmek için mutlaka gerekli, ancak şu anda bu işi Andrew Kelley üstleniyor
    • Bazı günler muhasebe işi yapıyor, bazı günler programlama yapıyor; programlama yaptığı günleri iyi günler olarak görüyor
    • Zig 0.15’in IO reader / IO writer arayüz değişikliği; optimum noktayı bulma, API tasarlama ve test etme, ayrıca diğer programlama dilleriyle karşılaştırıp yeni çözümler aramanın sonucuydu, ancak sonrasında 6 ay boyunca standart kütüphane ve ekosistem projelerini düzeltmek gerekti

  • Tükenmişlik ve tavsiyeler

    • Tükenmişliğin, çok çaba harcanmasına rağmen bu çabanın karşılığının yeterince görülmediği durumlarda ortaya çıktığını düşünüyor
    • Andrew Kelley, çok emek vermesine rağmen mutlu kullanıcılar, Zig sürümleri, sürüm notları ve iyileştirmeler gibi karşılıkları gördüğü için genel olarak tükenmişliğe karşı korunuyor
    • IO değişikliği gibi karşılığın aylarca geciktiği işler tükenmişlik gibi hissettirebilir, ancak sonunda karşılığı geldiğinde durum düzeliyor
    • Tükenmişlik yaşayan insanlara önce egzersiz yapmayı, yeterince uyumayı ve sağlıklı beslenmeyi tavsiye ediyor
    • Yapılan işten nefret ediliyorsa ya da şirketin dünyaya değerli bir katkı sunmadığı hissediliyorsa ama yine de çok çalışmak gerekiyorsa, bu tükenmişlik için uygun koşulları oluşturuyor
    • Bu durumda başka bir iş aramak ya da girişim kurmak gibi kendi işini yaratmanın zor yolunu seçmek bir seçenek; ayrıca “ruhsuz bir şirkette” çalışılıyorsa saat 17:00’de eve gidip başka şeylerle uğraşmayı ve fazla çalışmamayı öneriyor

  • Hayranlık duyduğu projeler ve tarayıcı çeşitliliği

    • Hayranlık duyduğu ilk proje olarak Linux gösteriliyor
    • Yalnızca tescilli işletim sistemlerinin olduğu bir dünya çok daha kötü olurdu; Linux’un yalnızca özgür ve açık kaynak geliştiricilere değil, dünya genelindeki ülkelerle şirketlerin de ücretsiz biçimde iş kurabilmesine olanak sağladığı ve bunun ekonomiye de iyi geldiği değerlendiriliyor
    • İkinci sırada Blender var; profesyonel olarak kullanılan, çok para ve geliştirici gücüne sahip şirketlerle rekabet edip onları yenebilen bir açık kaynak projesi ve kâr amacı gütmeyen kuruluş olması özellikle takdir ediliyor
    • Üçüncü olarak VLC anılıyor; geçmişte FFmpeg’e katkı verdiği dönemde, VLC’ye veya bağımlı kütüphanelerine katkı sunan bir kişinin VideoLAN Dev Days seyahat masraflarını VLC organizasyonunun karşıladığını hatırlatıyor
    • Firefox kullanmasının nedeni, tarayıcı çeşitliliğine dair duyduğu endişe
    • Microsoft Internet Explorer’ı sonlandırdıktan sonra geriye kalan başlıca tarayıcıların yalnızca Chromium, Safari ve Firefox olduğu, Chromium’un pazarın büyük kısmını elinde tutmasının web için sorun yarattığı düşünülüyor
    • Son dönemde Mozilla’dan memnun olmadığını; kâr amacı gütmeyen bir kuruluş olmasına rağmen çok fazla yozlaşma bulunduğunu ve bunun kullanıcılarla hizalanmayan örnekler gibi göründüğünü ifade ediyor
    • Chromium Google’ın, Safari Apple’ın elinde; Firefox ise gerilemede görünüyor, bu yüzden alternatif az ve yeni tarayıcı projeleri olgunlaşana kadar ne yapılması gerektiğini bilmediğini söylüyor

  • 2015’e geri dönse yine Zig’i başlatır mı

    • 2015 yılına geri dönse kesinlikle Zig’i başlatacağını söylüyor
    • OkCupid’den ayrılıp Zig’e tam zamanlı başladığı gün, hayatının sonraki gidişatına bakıldığında yaşamındaki en iyi gündü
    • Zig ona derin bir tatmin, bağımsızlık, özdeğer duygusu ve topluma katkıda bulunduğu hissini verdi
    • Kendisini temelde istihdam edilmesi zor bir insan olarak görüyor; mutlu olabilmesi için kendi kendisinin patronu olması gerekiyordu ve bu duruma ulaştıktan sonra mutluluğu buldu

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Lobste.rs yorumları
  • Zig Software Foundation dışındaki insanların da Andrew ile çekirdek ekibin projeyi ileri taşırken sahip olduğu tutku ve felsefeyi görmesini isterdim
    JetBrains’in röportajı daha kışkırtıcı hale getirip viral olmayı hedeflemesini suçlayamam, ama sonuçta en iyi sorular Zig ve Rust karşılaştırması değil; kâr amacı gütmeme, sürdürülebilirlik ve sevgiyle inşa edilen Zig hakkındaki sorulardı
    Bence Andrew, projenin arkasında sessizce yanan insani tarafı dünyaya çok iyi gösterdi
    • Dürüst olmak gerekirse JetBrains’in bunu özellikle kışkırtıcı bir yöne çektiğini de pek düşünmüyorum
      Video, Zig’i epey kullanmış kişilerden çok Zig’i merak eden insanları ve projenin nasıl yürütüldüğüyle ilgilenenleri hedefliyor gibiydi; sadece bu kitlenin zaten bilebileceği konuları kaçınmadan gündeme getirdi
      Röportajı yapan kişi de ortalığı alevlendirmek yerine Andrew’un sözlerinin kendi kendine öne çıkmasına izin verdi; bu tür bir röportaj için oldukça düşünceliydi
      Yine de altyazıya koymayı seçtikleri bazı kelimelere gülmedim değil; Zig’le ilgilenip de Linux’un ya da soyutlamanın ne olduğunu bilmeyen kaç kişi vardır emin değilim
      Genel olarak hem Zig’in sunuluş biçimi hem de JetBrains pazarlama ekibi hakkında bende oldukça olumlu bir izlenim bıraktı
  • Andrew videonun ortalarında, Zig ve yapay zeka kullanımına yardımcı olmak için benim yaptığım bir araçtan bahsetti; denemek isteyenler için söyleyeyim, bu araç zigdoc: github.com/rockorager/zigdoc
    Temelde Zig standart kütüphanesinin ve build graph içinde bulunan bağımlılıkların dokümantasyonunu komut satırından görüntülemeyi sağlayan bir araç
  • Videonun son birkaç saniyesinde Andrew’un mutlu olduğunu söylemesi gerçekten çok hoştu
  • “Ödünsüz sevgi emeği” ifadesi tam oturuyor
    1.0’ı aceleye getirmeme çerçevesi çekici, ama Zig bu ekosistem değişimlerinin sarsıntısını göğüsleyen kullanıcılara sahip olduğu için de şanslı
  • Gömülü sistemler tarafında ana araç yıllardır C’ydi
    C++ değil, doğrudan C
    Bir sonraki gömülü projemi Zig’le mi yoksa Rust’la mı yapacağımı sürekli düşünüyordum; şimdi ise “zamanı geldi” duygusu oluştu
    Bu röportaj benim için belirleyici bir dönüm noktası olabilir ve burada güçlü biçimde bağ kurduğum genel bir hava var
  • Andrew’un LLVM’den uzaklaşmak isteme nedenine verdiği yanıt gerçekten çok iyiydi
    Zig’in temel özelliklerinin parçası olan ve bu yüzden ekibin daha fazla kontrol sahibi olması gereken alanı çok iyi ele aldı