Zig: Tüm paket yönetimi işlevlerini derleyiciden build sistemine taşıyor

 (ziglang.org)
1 puan yazan GN⁺ 5 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Zig, build.zig ve build sisteminin ayrı süreçlere ayrıldığı akışa uyum sağlayarak paket yönetimi mantığını derleyici çalıştırılabilir dosyasının dışındaki maker sürecine taşıdı
  • zig build, zig fetch, zig init, zig libc maker tarafına taşınırken HTTP, TLS, Git, sıkıştırma ve build.zig.zon işleme kodu kaynak biçiminde dağıtılacak
  • Bu yapıda paket yönetimi işlevleri derleyiciyi yeniden derlemeden düzeltilebiliyor ve maker ReleaseSafe ile derlendiği için ağ işlemlerinde güvenlik kontrolleri de etkinleşiyor
  • Asıl amaç build server protocol'ü ortaya çıkararak ZLS'yi engelleyen --build-runner değişikliği sorununu çözmek; yeni süreç ağacında maker, configurer'ın ebeveyni olarak kalıp yapılandırmanın yeniden çalıştırılmasını daha kararlı biçimde yönetebiliyor
  • Kullanıcıya etkisi büyük değil ancak Zig çalıştırılabilir dosyası 14.1MiB'den 13.5MiB'e inerek %4 küçülüyor ve --maker-opt ile --zig-lib-dir sırasıyla ZIG_DEBUG_MAKER ve ZIG_LIB_DIR ortam değişkenleriyle değiştiriliyor

Paket yönetimi mantığının taşınması

  • Zig, kullanıcı build.zig betikleri ile build sisteminin kendisi ayrı süreçlere ayrıldıktan sonra paket yönetimi mantığını da build sistemi tarafında konumlandıran bir yapıya geçti
  • maker sürecine taşınan alt komutlar şunlar:
    • zig build
    • zig fetch
    • zig init
    • zig libc

Derleyici çalıştırılabilir dosyasından çıkarılan kod

  • Daha önce derleyici çalıştırılabilir dosyasının içinde bulunan büyük kod bölümleri artık kaynak biçiminde dağıtılıyor
    • Paket getirme mantığı
    • HTTP istemcisi ve ağ iletişimi
    • TLS ve ilgili kriptografi
    • Git protokolü
    • xz, gzip, zstd, flate, zip
    • build.zig.zon dosyasının ayrıştırılması, doğrulanması ve diğer işlemleri
  • Bu işlevler, derleyiciyi yeniden derlemeye gerek kalmadan yamalanabildiği için kullanıcılar ve katkıda bulunanlar daha kolay deney yapabiliyor
  • maker çalıştırılabilir dosyası ReleaseSafe modunda derlendiğinden, paket yönetiminin ağ işlemlerinde güvenlik kontrolleri açık oluyor
  • Ağ iletişimi ve dosya hash'lemede kullanılan kriptografi kodu, ana makinede kullanılabilen özel CPU komutlarından yararlanabiliyor

Süreç yapısı ve build server

  • Başlangıçtaki motivasyon, build server protocol'ü görünür hâle getirerek ZLS'yi engelleyen sorunu çözmekti
  • Önceki yapıda zig build, derleyici ve paket yöneticisini birlikte üstleniyor; onun altında builder ise kullanıcı build.zig mantığını ve build sistemi uygulamasını barındırıyordu
  • maker/configurer ayrımından sonraki yapı şöyleydi:
    • zig build: derleyici + paket yöneticisi
    • configurer: kullanıcı build.zig mantığı
    • maker: build sistemi
  • Bu yapıda uzun süre çalışan zig build --watch, build.zig veya ilgili dosyalarda değişiklik algıladığında configurer'ı yeniden çalıştırmak zorundaydı; bunun için maker'ın sonlanıp zig build'e paket yönetimi mantığını tekrar yürütme fırsatı vermesi gerekiyordu
  • Yeni yapıda zig build yalnızca derleyiciyi üstleniyor; onun altında maker build sistemi ile paket yöneticisini yönetiyor ve configurer maker'ın alt süreci oluyor
  • Yapılandırmanın yeniden çalıştırılması gerektiğinde de maker ebeveyn süreç olarak yaşamaya devam edebiliyor
  • Planlanan build server'da ise sunucu kapandıktan sonra istemcinin yeniden bağlanması yerine, istemciye yapılandırma değişikliği bildiren bir yapı mümkün hâle geliyor

Gözlemlenebilir değişiklikler

  • Çoğu değişiklik uyumsuzluk yaratmasa da, kullanıcının görebileceği bazı farklar var
    • Zig çalıştırılabilir dosyasının ikili boyutu: LLVM'siz ReleaseSmall ölçümünde 14.1MiB'den 13.5MiB'e düşerek %4 küçülme
    • --maker-opt bayrağı, ZIG_DEBUG_MAKER ortam değişkeniyle değiştirildi
    • --zig-lib-dir bayrağı, ZIG_LIB_DIR ortam değişkeniyle değiştirildi

Zig 0.17.0 öncesinde kalan engelleyici konular

İlgili okumalar

1 yorum

 
GN⁺ 5 시간 전
Hacker News yorumları

  • Zig, Go ve Python geliştiricileri bazen yakıt deposundan soğutma sıvısını çıkardıklarını duyuruyor; destekçileri de bunun dil için iyi olduğunu ve performansı ciddi ölçüde artıracağını söyleyerek seviniyor
    Ama en başta soğutma sıvısını neden yakıt deposuna koydukları daha çok merak uyandırıyor

    • Bu tür projelerin erken dönemlerinde, tasarımın sonuçlarını derinlemesine düşünmekten çok tek tek geliştiricilerin rahatlığı öncelik kazanabiliyor
      Paket yönetimini derleyicinin içine koymak rahattı; ama dil ve araçlar yaygın kullanılmaya başlayınca, birey için avantajlı olan özellik benimsenmenin önünü kesen bir borca dönüşüyor
      Pek çok projede geliştiriciler, “doğru yapmak için gereken zor işi” yapmaktan kaçınmak için kolay yolu seçiyor; başkaları da o zor işi yapmak istemediğinden bu yaklaşım teamül haline geliyor
    • Burada savunulabilecek bir mantık da var
      Bir paket yöneticisini derleme sisteminin içinde uygularken derleyicide de bırakmak istiyorsanız, önce derleyici ile derleme sistemi arasına nasıl bir soyutlama koyacağınıza karar vermeniz gerekir
      Bu, import sistemini ve dilin temel parçalarını da etkiler; bu kısımların doğru tasarlanması gerekir ve sonradan değiştirmesi de zordur
      Başta paket yönetimi ile derleyiciyi sıkı biçimde bağlayıp istenen programcı deneyiminden geriye doğru tasarlamak, sonra uygulamayı değiştirmek kullanıcılar üzerinde daha az etki yaratabilir
      Özellikle Python’ın import sisteminin, paket yönetiminin birçok farklı şekilde yapılmasını desteklemek zorunda kaldığı için çok karmaşık ve kusurlu hale geldiğini düşünüyorum
      Buna karşılık Go, en baştan paket yönetimi düşünülerek tasarlandığından import ile ilgili sözdizimi nispeten küçük ve temiz. Elbette tüm tasarım kararlarına katılıyorum demek değil
    • Kulağa öyle gelmesinin nedeni, sanki hiç bir şey inşa etmemiş olman gibi
      Küçük bir üründe bile bileşenlerin nasıl etkileşeceğini öngörmek zordur ve sürekli düzeltme yapmak gerekir
      Şimdi bir kendi kendini barındıran C alternatifi dil yaptığını düşün
    • Performans konusunda da tam olarak aynı şeyi hissediyorum. Belirli bir programlama diliyle ya da benim optimizasyonlarımla da ilgisi yok
      Hız artışı ne kadar büyükse o kadar seviniliyor; ama optimizasyonların çoğu zekice teknikler değil, profiler ile “aa, soğutma sıvısının yakıt deposunda olmaması gerekiyordu” noktasını bulma işi
      Çoğu performans darboğazı, donanımın ya da problemin kendisinin özsel sınırlarından kaynaklanmaz
      Sonucu elde etmek için gereken asgari bir iş miktarı vardır; ama bir uygulamanın yavaş olmasının nedeni neredeyse her zaman bunun üstüne eklenen ıvır zıvırdır
    • Zig veya Python’ı pek bilmediğim için yargılamam zor, ama Go’da böyle bir his hiç yaşamadım. Bunun ne zaman olduğunu bilmiyorum

  • Zig geliştirme süreci gerçekten sağlıklı bir atmosfere sahipmiş gibi geliyor

    • Son zamanlarda Zig’e bakınca, yazılım geliştirmenin bir zanaat olarak ölmediğini ya da LLM’lerle ikame edilmediğini kanıtlıyor
      LLM’leri her gün kullanıyorum ve birçok problem türünde şaşırtıcı derecede iyi olduklarını kabul ediyorum; ama LLM’in yaptığı bir programlama dili istemem
      Bir programlama dilindeki her kod satırı, karar ve ödün önemlidir
      Sadece havaya göre tasarlanıp kodlanmış bir dil felaket olur
      Hiçbir model, beni tersine ikna edecek kod göstermedi. Fable bile önceki en iyi modellerden açıkça daha iyi olsa da durum aynı
      Modelin istediği bir şey yoktur, anlamlı bir görüşü yoktur ve bir dilde rahatlığın ve rahatsızlığın ne olduğunu bilmez. Yeterince karmaşık GUI veya CLI arayüzlerinde de durum aynı
      Zig gibi bir dil, Zig’i basitçe kopyalamadığı sürece LLM’den çıkamaz; kopyalasa bile daha kötü bir kopya olur
      Burada LLM ile kopyalamaktan kastım kaynak ağacını kelimesi kelimesine cp yapmak değil; LLM’in bir spesifikasyon yazması ve başka bir LLM’in o spesifikasyona göre dili uygulaması gibi bir şey
    • Zig ile bir şeyler yapmak da epey eğlenceli
      Bir bootloader yaptım ve UEFI üzerinde çalıştım; kişisel olarak C ile yapmaktan çok daha kolaydı
      Yine de yeni ve parlak bir şey öğrenmenin eğlencesi olduğu için önyargımın arttığı da doğru

  • Bu değişikliğin Zig’de @cImport’u kaldırıp derleme sistemine taşımaya yol açan değişiklik olup olmadığını merak ediyorum
    Tamamen kullanıcı deneyimi meselesi ve derleme sistemi ile derleyiciyi ayırmanın bakımcılar için önemli olduğunu anlıyorum; yine de geliştirme kararlılığının kullanıcı deneyiminin önüne geçmesi biraz üzücü
    Doğru karar olsa da üzücü; @cImport’un bu dilin güçlü bir öldürücü özelliği olduğunu düşünüyorum

    • Pek öyle değil
      Bu değişiklik, üçüncü taraf paketleri indiren ve arşivden çıkaran kodla ilgili
      @cImport değişikliği, Zig’in LLVM/libclang bağımlılığını bir gün isteğe bağlı hale getirme ve daha sonra üçüncü taraf pakete çıkarabilme çalışmasının parçasıydı; ama doğrudan ilişkili görünmüyor

  • Uzun vadeli hedefin derleme sistemini bir WebAssembly VM içine taşımak olduğunu bir yerde okumuştum
    Öyleyse harika bir iş

    • Bunun derlemede nasıl bir avantajı olduğunu merak ediyorum

  • Zig için iyi bir değişiklik
    Go’dan Zig’e geçme isteğim oldukça güçlü, ama şimdilik kenardan izlemekten de keyif alıyorum

    • Kullanım senaryosuna bağlı olarak ikisini de kullanabilirsin; belki de kullanmalısın

  • Her dil kendi paket sistemini yaptığında büyük bir fırsatı kaçırmışız gibi hissediyorum
    Tek istisna C/C++; onda da iyi ya da kötü, yeterince yerleşmiş bir şey yok
    Bu tercih, ileride birden çok dili karıştırarak kullanmak gerektiğinde çok karmaşık süreçler doğurabilir
    Paketleme sistemleri işleri kolaylaştırır; ama başka bir dil kullanmanız gerektiği anda sonraki süreci daha karmaşık hale getirir

    • Neyi kaçırdığımızı düşündüğünü merak ediyorum
      Tüm diller için tek bir derleme sistemi mi istiyorsun? Bazel gibi sistemler var ve çok dilli projelerde de sık kullanılıyorlar; ama pratikte dile özgü bilgiye sahip derleme sistemlerinin çok daha kolay yönetildiği kanıtlanmış gibi
    • C++’ta standartlaştırılmış bir paketleme sisteminin olmamasının aslında iyi olduğunu düşünüyorum
      Çünkü bağımlılık eklemeden önce dikkatlice düşünmeye zorluyor
      Bu tür bağımlılıkların çoğu zaman güvenlik açıkları gibi gizli maliyetleri oluyor
      Önemli sistemlerin hatırı sayılır bir kısmı C++ ile yazıldığı için, her paketi düzgün denetlemeden kolay erişilebilir onlarca üçüncü taraf pakete bağımlı olmak fazlasıyla riskli
    • C, çeşitli sorunları düzeltip bir paket yöneticisi eklemeli ya da birini resmen tanımalıydı
      Zig bu boşluğu dolduruyor
    • Dünya hâlâ iyi bir çapraz platform çok dilli derleme sistemi üzerinde standartlaşamadı
      Aslında böyle derleme sistemleri sadece Buck ve Bazel; ikisi de arkalarındaki dev kuruluşlardan gelen fazlasıyla yük taşıyor
      Üzücü bir durum
    • Conan ve vcpkg yeterince yerleşmiş durumda

  • Sorumlulukların ayrımı çok ikna edici şekilde yapılmış