Zig: सभी पैकेज मैनेजमेंट फीचर को compiler से build system में शिफ्ट किया

 (ziglang.org)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Zig ने build.zig और build system को अलग process में बांटने वाले flow के अनुरूप, package management logic को compiler executable से बाहर maker process में शिफ्ट किया
  • zig build, zig fetch, zig init, zig libc के maker की ओर जाने के साथ HTTP, TLS, Git, compression, build.zig.zon handling code source form में distribute किए जाते हैं
  • इस structure में compiler को rebuild किए बिना package management features को ठीक किया जा सकता है, और maker ReleaseSafe में compile होता है, जिससे networking tasks के लिए safety checks भी enabled होते हैं
  • मूल उद्देश्य build server protocol को expose करके ZLS को रोक रही --build-runner change की समस्या सुलझाना है, और नए process tree में maker, configurer का parent बना रहता है, जिससे configuration rerun को अधिक स्थिर रूप से handle किया जा सकता है
  • Users पर असर बड़ा नहीं है, लेकिन Zig executable 14.1MiB से 13.5MiB होकर 4% छोटा होता है, और --maker-opt व --zig-lib-dir की जगह क्रमशः ZIG_DEBUG_MAKER, ZIG_LIB_DIR environment variables लेते हैं

Package management logic का स्थानांतरण

  • Zig ने user build.zig script और build system के खुद अलग processes में बांटे जाने के बाद, package management logic को भी build system की तरफ रखने वाला structure अपनाया
  • maker process में शिफ्ट किए गए subcommands ये हैं
    • zig build
    • zig fetch
    • zig init
    • zig libc

Compiler executable से निकला code

  • पहले compiler executable के अंदर मौजूद बड़े code areas अब source form में distribute किए जाते हैं
    • Package fetch करने का logic
    • HTTP client और networking
    • TLS और संबंधित cryptography
    • Git protocol
    • xz, gzip, zstd, flate, zip
    • build.zig.zon file की parsing, validation, और अन्य handling
  • इन features को compiler को दोबारा build किए बिना patch किया जा सकता है, जिससे users और contributors के लिए experiment करना आसान होता है
  • maker executable ReleaseSafe mode में compile होता है, इसलिए package management के networking tasks में safety checks enabled रहते हैं
  • Networking और file hashing में इस्तेमाल होने वाला cryptography code host पर उपलब्ध special CPU instructions का उपयोग कर सकता है

Process structure और build server

  • मूल motivation build server protocol को expose करके ZLS को रोक रही समस्या को हल करना था
  • पुराने structure में zig build compiler और package manager दोनों की जिम्मेदारी लेता था, और उसके नीचे builder में user build.zig logic और build system implementation होते थे
  • maker/configurer separation के बाद structure ऐसा था
    • zig build: compiler + package manager
    • configurer: user build.zig logic
    • maker: build system
  • इस structure में लंबे समय तक चलने वाले zig build --watch को build.zig या related files में बदलाव detect होने पर configurer को फिर से run करना पड़ता था, और इसके लिए maker को exit करना होता था ताकि zig build को package management logic repeat करने का मौका मिले
  • नए structure में zig build केवल compiler संभालता है, और उसके नीचे maker build system और package manager को संभालता है, जबकि configurer maker का child process बनता है
  • Configuration को फिर से run करना पड़े तब भी maker parent process के रूप में लगातार alive रह सकता है
  • Planned build server में server shutdown के बाद client के दोबारा connect करने के बजाय, client को configuration changes notify करने वाला structure संभव हो जाता है

दिखने वाले बदलाव

  • अधिकतर बदलाव incompatible नहीं हैं, लेकिन users को दिखने वाले कुछ अंतर हैं
    • Zig executable binary size: LLVM के बिना ReleaseSmall के आधार पर 14.1MiB से 13.5MiB तक घटकर 4% कमी
    • --maker-opt flag की जगह ZIG_DEBUG_MAKER environment variable लेता है
    • --zig-lib-dir flag की जगह ZIG_LIB_DIR environment variable लेता है

Zig 0.17.0 से पहले बचे blocking issues

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की राय

  • Zig, Go, Python के डेवलपर कभी-कभी घोषणा करते हैं कि उन्होंने फ्यूल टैंक से कूलेंट हटा दिया है, और समर्थक खुशी मनाते हैं कि यह भाषा के लिए अच्छा है और performance भी काफ़ी बेहतर होगी
    लेकिन मुझे ज़्यादा उत्सुकता इस बात की है कि शुरुआत में कूलेंट को फ्यूल टैंक में रखा ही क्यों गया था

    • ऐसे प्रोजेक्ट्स के शुरुआती दौर में, design के नतीजों पर गहराई से सोचने के बजाय किसी एक developer की सुविधा को प्राथमिकता मिलना आसान होता है
      package management को compiler के अंदर रखना सुविधाजनक था, लेकिन जब भाषा और tooling व्यापक रूप से इस्तेमाल होने लगते हैं, तो जो feature किसी व्यक्ति के लिए फायदेमंद था वही adoption रोकने वाला debt बन जाता है
      कई प्रोजेक्ट्स में developer “इसे सही ढंग से करने के लिए ज़रूरी कठिन काम” से बचने के लिए आसान रास्ता चुनते हैं, और चूंकि दूसरे लोग भी वह कठिन काम नहीं करना चाहते, वही प्रथा बन जाती है
    • इसके पक्ष में भी एक तर्क है
      अगर build system के अंदर package manager implement करते हुए उसे compiler में भी रखना हो, तो पहले यह तय करना होगा कि compiler और build system के बीच कैसी abstraction रखी जाए
      इसका असर import system और भाषा के मूल हिस्सों पर भी पड़ता है, और इन हिस्सों को ठीक से design करना पड़ता है; बाद में इन्हें बदलना भी मुश्किल होता है
      शुरुआत में package management और compiler को कसकर जोड़कर desired programmer experience से उल्टा design किया जाए, और बाद में implementation बदली जाए, तो users पर असर कम हो सकता है
      खासकर Python का import system package management के कई तरीकों को accommodate करने के कारण बहुत complex और flawed हो गया है, ऐसा मुझे लगता है
      इसके उलट Go को शुरू से package management को ध्यान में रखकर design किया गया, इसलिए import से जुड़ा syntax अपेक्षाकृत छोटा और साफ़ है। बेशक, मैं हर design decision से सहमत नहीं हूं
    • लगता है आपने कभी कुछ बनाया नहीं है, इसलिए ऐसा सुनाई देता है
      छोटे product में भी यह अनुमान लगाना मुश्किल होता है कि उसके components आपस में कैसे interact करेंगे, इसलिए बार-बार सुधार करना पड़ता है
      अब सोचिए कि आप self-hosting C replacement language बना रहे हैं
    • performance को लेकर भी मुझे बिल्कुल ऐसा ही महसूस होता है। इसका किसी खास programming language या मेरी optimization से कोई लेना-देना नहीं है
      speed gain जितना बड़ा होता है, लोग उतना खुश होते हैं, लेकिन ज़्यादातर optimization कोई चालाक technique नहीं होती; वह profiler से यह ढूंढना होता है कि “अरे, कूलेंट फ्यूल टैंक में नहीं होना चाहिए”
      ज़्यादातर performance bottleneck hardware या समस्या की अपनी मूलभूत सीमा नहीं होते
      result पाने के लिए न्यूनतम काम तो करना ही होता है, लेकिन applications धीमी लगभग हमेशा उस पर जोड़े गए फालतू सामान की वजह से होती हैं
    • Zig या Python के बारे में मुझे पर्याप्त जानकारी नहीं है इसलिए आकलन करना मुश्किल है, लेकिन Go में मुझे बिल्कुल ऐसा महसूस नहीं हुआ। नहीं पता ऐसा कब हुआ था

  • Zig development सच में healthy माहौल जैसा लगता है

    • आजकल Zig को देखकर लगता है कि software development नाम का craft मरा नहीं है और LLM से replace भी नहीं हुआ है
      मैं LLM रोज़ इस्तेमाल करता हूं और मानता हूं कि कई तरह की समस्याओं में वे हैरान करने वाले तरीके से अच्छे हैं, लेकिन मैं LLM द्वारा बनाई गई programming language नहीं चाहता
      programming language की हर code line, decision और trade-off मायने रखता है
      सिर्फ vibe के आधार पर design और code की गई भाषा disaster होगी
      किसी model ने कभी ऐसा code नहीं दिखाया जिससे मैं इसके उलट आश्वस्त हो सकूं। Fable भी पहले के best models से स्पष्ट रूप से बेहतर है, लेकिन बात वही है
      model की अपनी कोई इच्छा नहीं होती, कोई meaningful राय नहीं होती, और उसे नहीं पता कि भाषा में comfort और discomfort क्या होता है। पर्याप्त complex GUI या CLI interface में भी यही बात है
      Zig जैसी भाषा LLM से नहीं आ सकती, जब तक कि वह बस Zig की नकल न करे; और नकल भी होगी तो खराब copy होगी
      यहां LLM से नकल करने का मतलब source tree को literally cp करना नहीं है, बल्कि LLM spec लिखे और दूसरा LLM उस spec के अनुसार भाषा implement करे—ऐसा है
    • Zig में चीज़ें बनाना भी काफ़ी मज़ेदार है
      मैंने bootloader बनाया और UEFI पर काम किया, और निजी तौर पर यह C की तुलना में कहीं आसान लगा
      हालांकि नई और चमकदार चीज़ सीखने का मज़ा भी था, जिससे bias बढ़ गया होगा

  • सोच रहा हूं कि क्या यह वही बदलाव है जिसकी वजह से Zig में @cImport को हटाकर build system में ले जाया गया
    यह पूरी तरह user experience का सवाल है, और समझता हूं कि build system और compiler को अलग करना maintainers के लिए महत्वपूर्ण है, फिर भी थोड़ा अफ़सोस है कि development stability user experience से पहले आ रही है
    फैसला सही है, लेकिन दुखद है, और मुझे लगता है @cImport इस भाषा का एक strong killer feature था

    • ज़रूरी नहीं
      यह बदलाव third-party packages download और extract करने वाले code से जुड़ा है
      @cImport वाला बदलाव Zig की LLVM/libclang dependency को किसी दिन optional बनाने, और आगे चलकर third-party package में निकालने की कोशिश का हिस्सा था, लेकिन यह सीधे तौर पर संबंधित नहीं लगता

  • कहीं पढ़ा था कि long-term goal build system को WebAssembly VM के अंदर ले जाना है
    अगर ऐसा है तो यह कमाल की बात है

    • build में इससे क्या फायदा होगा, यह जानने की उत्सुकता है

  • Zig के लिए अच्छा बदलाव है
    Go से Zig पर जाने का मन काफ़ी करता है, लेकिन फिलहाल किनारे से देखना भी अच्छा लग रहा है

    • use case के आधार पर दोनों इस्तेमाल कर सकते हैं, और शायद करना भी चाहिए

  • जब भी कोई भाषा अपना package system बनाती है, मुझे बस लगता है कि हमने कोई बड़ा मौका खो दिया
    इकलौता exception C/C++ है, जहां अच्छा हो या बुरा, पर्याप्त रूप से स्थापित कुछ नहीं है
    ऐसा चुनाव बाद में कई भाषाओं को मिलाकर इस्तेमाल करना पड़े तो बहुत complex process बना सकता है
    packaging system काम आसान बनाते हैं, लेकिन जैसे ही आपको दूसरी भाषा इस्तेमाल करनी पड़ती है, आगे की प्रक्रिया और complex हो जाती है

    • जानना चाहूंगा कि आपको क्या लगता है कि हमने क्या खोया
      क्या आप सभी भाषाओं के लिए एक build system चाहते हैं? Bazel जैसे system मौजूद हैं और multi-language projects में अक्सर इस्तेमाल होते हैं, लेकिन व्यवहार में language-specific knowledge वाले build system को संभालना कहीं आसान साबित हुआ लगता है
    • C++ में standardized packaging system न होना मुझे उल्टा अच्छा लगता है
      क्योंकि इससे dependency जोड़ने से पहले गंभीरता से सोचना पड़ता है
      ऐसी dependencies में अक्सर security vulnerabilities जैसी छुपी लागतें होती हैं
      कई critical systems C++ में लिखे गए हैं, इसलिए आसानी से उपलब्ध dozens third-party packages पर, हर package का ठीक से audit किए बिना निर्भर होना बहुत risky है
    • C को कई समस्याएं ठीक करनी चाहिए थीं और package manager जोड़ना चाहिए था या किसी एक को officially मान्यता देनी चाहिए थी
      Zig उसी खाली जगह को भर रहा है
    • दुनिया अभी तक एक अच्छे cross-platform multi-language build system पर standardize नहीं कर पाई है
      असल में ऐसे build systems सिर्फ Buck और Bazel हैं, लेकिन दोनों अपने पीछे मौजूद giant organizations का बहुत ज़्यादा baggage लेकर आते हैं
      यह अफ़सोस की बात है
    • Conan और vcpkg पर्याप्त रूप से established हैं

  • separation of concerns बहुत convincing तरीके से किया गया है