टाइप रिज़ॉल्यूशन का पुनःडिज़ाइन और भाषा में बदलाव

• Zig compiler की type resolution logic को पूरी तरह से फिर से डिज़ाइन किया गया है, जिससे इसकी आंतरिक संरचना सरल हुई है और यूज़र को भी दिखने वाले सुधार मिले हैं
• नई डिज़ाइन type field analysis को lazy तरीके से संभालती है, इसलिए uninitialized type की विस्तृत संरचना को अनावश्यक रूप से जाँचा नहीं जाता
• dependency loop error message को अधिक ठोस बनाया गया है, ताकि लूप के कारण को स्पष्ट रूप से समझा जा सके
• incremental compilation फीचर में ज़रूरत से ज़्यादा analysis की समस्या और कई bugs को ठीक किया गया है, जिससे build speed में काफ़ी सुधार हुआ है
• इस बदलाव में दर्जनों bug fixes और छोटे language improvements शामिल हैं, जो कुल मिलाकर Zig compiler की performance और developer experience को मजबूत करते हैं

---

टाइप रिज़ॉल्यूशन लॉजिक का पुनःडिज़ाइन

• लगभग 30,000 lines वाले PR को merge किया गया है, जिसमें Zig compiler की type resolution logic को अधिक तार्किक और सहज संरचना में फिर से लिखा गया है
  • इस प्रक्रिया में compiler की आंतरिक संरचना को व्यवस्थित किया गया, और इसका सीधा लाभ यूज़र को भी मिलता है
• compiler को type field analysis को lazy evaluation के साथ करने के लिए बदला गया है, इसलिए uninitialized type की विस्तृत संरचना को अनावश्यक रूप से नहीं खंगाला जाता
  • उदाहरण कोड में, यदि @compileError field वाला struct केवल namespace के रूप में इस्तेमाल हो, तो पहले compile error आता था, लेकिन अब यह सामान्य रूप से compile हो जाता है
  • इससे std.Io.Writer जैसे namespace-प्रकार के type का उपयोग करते समय अनावश्यक code dependency से बचाव होता है

dependency loop error message में सुधार

• पहले dependency loop error message अस्पष्ट हुआ करता था, लेकिन अब यह लूप के कारण और स्थान को स्पष्ट रूप से दिखाता है
  • उदाहरण कोड में, जब Foo और Bar struct एक-दूसरे को refer करते हैं, तो error message हर type की dependency location को विस्तार से दिखाता है
  • message में loop length, हर field declaration की location, और alignment query की location शामिल होती है
• जटिल loops में भी यह पर्याप्त जानकारी देता है, जिससे समस्या की जड़ को आसानी से समझा जा सकता है

incremental compilation performance में सुधार

• इस बदलाव से incremental compilation फीचर के कई bugs ठीक किए गए हैं
  • खास तौर पर “over-analysis” समस्या को हल किया गया है, ताकि केवल बदले हुए हिस्से को फिर से compile किया जाए
  • नतीजतन, कई मामलों में compilation speed में बड़ा सुधार हुआ है
• डेवलपर्स Zig 0.15.1 या उससे ऊपर के version में incremental compilation को सक्षम करके बेहतर developer experience का लाभ ले सकते हैं

अन्य सुधार

• इस PR में दर्जनों bug fixes, छोटे language changes, और compiler performance improvements शामिल हैं
  • इनमें से ज़्यादातर बारीक या विशेष मामलों से जुड़े हैं
• पूरे बदलाव की सूची Codeberg के PR #31403 में देखी जा सकती है
• नया bug मिलने पर issue report करने की सिफारिश की गई है

बदलाव का महत्व

• type resolution logic के सरलीकरण और incremental compilation optimization से Zig compiler की stability और efficiency मजबूत हुई है
• डेवलपर्स को अब तेज़ और अधिक स्पष्ट feedback मिलेगा, और बड़े codebase में भी productivity बढ़ने की उम्मीद की जा सकती है

[GN⁺]

Hacker News की राय

• मैं इस devlog का लेखक हूँ
  भाषा बदलावों से होने वाले compatibility breakage को लेकर चिंता समझ में आती है, लेकिन मैं यह स्पष्ट करना चाहता हूँ कि इस बार compiler में हुआ बदलाव इतना व्यापक असर डालने वाला नहीं है
  उदाहरण के लिए, ZLS को नई branch पर build करते समय सिर्फ .{} को .empty में बदलने जैसा मामूली बदलाव करना पड़ा। यह std.ArrayList के default value हटने की वजह से था, और यह पहले से ही 1 साल से deprecated था
  Awebo प्रोजेक्ट में भी पूरे dependency tree में सिर्फ तीन जगह बदलाव करने पड़े — .empty बदलाव, comptime जोड़ना, और orelse @alignOf(T) जोड़ना
  ऐसे बदलाव ज़्यादातर Zig developers के लिए लगभग स्वचालित रूप से किए जाने लायक सरल बदलाव हैं
  इस PR का मुख्य बिंदु breakage नहीं, बल्कि bug fixes और incremental compilation improvements है

  • मैं उन commenters में से एक हूँ जो इस बदलाव को लेकर आलोचनात्मक लगे थे
    मुझे लगता है कि PR की quality और planning बहुत उच्च स्तर की है, और लेखक की मेहनत को कमतर दिखाने का मेरा बिल्कुल इरादा नहीं था
    बस इससे यह सीख मिली कि आगे मुझे और ज़्यादा टिप्पणियाँ जोड़कर, और सावधानी से अपनी राय रखनी चाहिए
  • मैं Zig में सीधे शामिल नहीं हूँ, लेकिन lib/std/multi_array_list.zig में जो comment जोड़ा गया है, उसे देखकर एक सवाल उठा
    समझ नहीं आ रहा कि @alignOf(T) को MultiArrayList(T) की definition में इस्तेमाल करने से circular dependency क्यों बनती है
    अगर T, MultiArrayList खुद भी हो, तो क्या वह पूरी तरह अलग monomorphic type नहीं होगा? लगता है मैं कुछ मिस कर रहा हूँ
    संबंधित कोड: लिंक

• मैं जानना चाहता हूँ कि production environment में Zig इस्तेमाल करने वालों का अनुभव कैसा है
  भाषा में बार-बार बदलाव होते हैं, तो update cycle या rewrite cycle कैसी रहती है, और क्या dependency packages कभी language version से पीछे रह जाते हैं
  Bun के Zig इस्तेमाल के बारे में तो पता है, लेकिन दूसरे उदाहरण भी सुनना चाहूँगा

  • मैं लगभग 2.5 लाख LoC के Zig compiler codebase को maintain कर रहा हूँ (roc-lang/roc)
    पिछले 1–2 साल में भाषा और standard library के बदलाव बिना किसी बड़े मुद्दे के आगे बढ़े हैं
    पहले upgrades झंझट वाले होते थे, लेकिन अब वे बस “थोड़ी असुविधा” जैसे लगते हैं
    अगर कोई Zig इस्तेमाल का अनुभव पूछे, तो यह हिस्सा इतना स्थिर है कि लगभग इसका ज़िक्र भी नहीं करता
  • मैंने tigerbeetle और sig जैसे दो production Zig codebases पर काम किया है
    ऐसे बड़े प्रोजेक्ट tagged releases के आधार पर upgrade करते हैं, और आम तौर पर कुछ दिन से कुछ हफ्तों में migration पूरा कर लेते हैं
    dependencies भी बहुत कम होती हैं, इसलिए upgrade का बोझ ज़्यादा नहीं होता
  • Zig 0.15 काफ़ी स्थिर है
    लेकिन कभी-कभी मामूली typo से SIGBUS compiler crash हो जाता है, जिससे debugging मुश्किल हो जाती है
    .zig-cache 173GB तक बढ़ गया था, जिससे ARM VPS पर समस्याएँ हुईं
    lightpanda को 0.14→0.15 पर ले जाना आसान रहा। 0.16 में भी शायद कोई बड़ा मुद्दा नहीं होगा
    लेकिन library developer के रूप में 0.16 के तेज़ बदलावों की रफ़्तार पकड़ना मुश्किल है
    अभी सिर्फ “dev” branch पर प्रयोगात्मक रूप से support कर रहा हूँ
  • मैं लगभग 20 हज़ार LoC का Zig 0.16 कोड DebugSafe mode में production में चला रहा हूँ
    मैंने Node.js/TypeScript module को Zig में rewrite किया, और वह 2 गुना तेज़ हो गया, जबकि memory usage 70% कम हो गया
    Zig का sqlite/JSON serialization support काफ़ी मज़बूत है, जो बड़ा फ़ायदा रहा
    कमी यह है कि closure या vtable syntax की अनुपस्थिति की वजह से code layering करना मुश्किल होता है
    Arcs और bumper allocator का इस्तेमाल करके memory safety सुनिश्चित की, और DebugSafe mode में ही चलाते रहने का इरादा है
    ReleaseFast में बदलने पर 25% speedup मिला, लेकिन safety खोने जितना फ़ायदा नहीं लगा
  • C++ का हमेशा backward compatibility बनाए रखने का वादा उल्टा भाषा के विकास को रोकने वाली गलती था
    भले ही code बदलना पड़े, लंबे समय में यह सही तरीका है

• Zig टीम की उपलब्धियों से मैं प्रभावित हूँ
  मैं Zig में बना ghostty terminal अक्सर इस्तेमाल करता हूँ, और वह बहुत स्थिर है
  लेकिन निजी तौर पर मैं Rust को पसंद करता हूँ
  Rust “closed world” model अपनाता है, जबकि Zig “open world” model चुनता है
  Rust में trait को explicitly implement करना पड़ता है, लेकिन Zig में type का shape मेल खा जाए तो वह काम करता है
  इससे Zig में शक्तिशाली metaprogramming संभव होती है, लेकिन type inference अस्पष्ट हो जाने से autocomplete, documentation, और LSP support मुश्किल हो जाते हैं

  • कोई ठोस उदाहरण जानना चाहूँगा
    आपकी बात सुनकर यह Go के interface जैसा लग रहा है, लेकिन मेरी समझ से Zig में इसका सीधा समकक्ष concept नहीं है

• kernel32 से Ntdll में बदलाव दिलचस्प लगा
  यह Linux user-space API पर भी लागू होने वाला विचार है
  खासकर kernel-user boundary पर error handling का तरीका मिलता-जुलता है
  लेकिन Linux में libc और kernel काफ़ी गहराई से जुड़े हुए हैं, इसलिए errno का इस्तेमाल ज़रूरी हो जाता है
  Windows में भी यह pattern क्यों बना, यह जानने की उत्सुकता है

  • errno या GetLastError() pattern thread से पहले के युग की विरासत हैं
    पहले cooperative scheduling होती थी, इसलिए global variable सुरक्षित माने जाते थे, लेकिन multi-core और threads आने के बाद यह ख़तरनाक हो गया
    इसलिए thread local उसका विकल्प बनकर आया

• types को namespace की तरह इस्तेमाल करने के बजाय, क्या भाषा में explicit namespace जोड़ना बेहतर नहीं होगा?

  • Zig language minimalism की दिशा में चलता है
    अगर कोई feature कई जगह optimization देता हो, तो वही समय होता है जब उसे जोड़ा जाता है
  • सच कहें तो यह workaround नहीं, बल्कि design की elegance है
    Zig में @import किसी file को struct में बदल देता है, और namespace को बस nested struct के रूप में व्यक्त किया जाता है
    यानी namespace वास्तव में एक और import ही है
    (अभी coffee पूरी नहीं हुई है, इसलिए शुद्धता की गारंटी नहीं)

• भाषा बदलाव की चर्चाओं में एक पहलू अक्सर नज़रअंदाज़ हो जाता है — यानी ecosystem पर असर
  अगर भाषा बार-बार टूटती है, तो सिर्फ apps नहीं बल्कि libraries, tools, tutorials वगैरह को भी लगातार साथ चलना पड़ता है
  नतीजतन ecosystem “एक बार बनाकर छोड़ दी गई” libraries के बजाय actively maintained projects की ओर झुकने लगता है
  शुरुआती language design phase में यह एक उचित trade-off हो सकता है, लेकिन लंबे समय में इसका असर ecosystem growth पर पड़ता है
  दूसरी नई भाषाएँ ऐसे change fatigue को कम करने पर काफ़ी मेहनत करती हैं
  Zig का यह approach क्या नतीजे लाता है, यह देखना भी दिलचस्प होगा

  • उदाहरण के तौर पर Blender addon ecosystem को देख सकते हैं
    Blender अक्सर API break करता है, लेकिन ज़्यादातर fixes मामूली होती हैं
    फिर भी किसी न किसी को उन्हें ठीक करना पड़ता है, और maintenance रुक जाए तो user को ख़ुद patch करना पड़ता है
    paid addons के बने रहने की संभावना ज़्यादा होती है, लेकिन वह भी गारंटी नहीं है
  • फिर भी मुझे लगता है कि Zig इसके लायक है
    जो libraries maintain नहीं होतीं, वे वैसे भी खराब code हैं
    Zig की आलोचना करने के बजाय, दूसरी भाषाओं (जैसे C3) का प्रचार करना बंद करना चाहिए

• Zig के PR में जो लिखा था कि “Chromium, boringssl, Firefox, Rust, advapi32.dll के SystemFunction036 को call करते हैं” — वह सही नहीं है
  ये पहले से ही ProcessPrng इस्तेमाल कर रहे हैं, और Windows 10 के बाद यह fail नहीं होता
  इसका संबंधित आधार Microsoft whitepaper में है
  RNG request कभी fail न हो, इस तरह इसे design किया गया है, और failure होने पर process को ही terminate कर दिया जाता है
  यानी high-quality randomness की गारंटी के लिए यह error code लौटाता ही नहीं

  • (यह उसी page के दूसरे devlog पर की गई reply है)

• Zig की language semantics ऊपर से सरल दिखती हैं, लेकिन उनके interaction काफ़ी सूक्ष्म हैं
  लगता है कि समय के साथ इससे C++ template rules की तरह जटिल edge cases पैदा हो सकते हैं

• 30 हज़ार lines वाला PR अपने आप में बड़ी उपलब्धि है
  लेकिन language semantics बदलना बहुत गंभीर बात है, इसलिए मैं चौंक गया
  समझता हूँ कि Zig अभी 1.0 से पहले है और बदलाव तेज़ी से हो रहे हैं, लेकिन “इस branch में semantics बदल दिए” जैसी casual phrasing थोड़ा अजीब लगी
  क्या इतने बड़े बदलाव Zig की अपनी संस्कृति का हिस्सा हैं, या फिर मैं ही समय से पीछे हूँ, यह जानना चाहता हूँ
  “modern Zig” जैसा वाक्यांश भी भाषा के तेज़ बदलावों की वजह से थोड़ा मज़ेदार लगा

  • लिखने का लहजा casual होने का मतलब यह नहीं कि रवैया हल्का या लापरवाह है
    devlog कोई marketing post नहीं, बल्कि insiders के लिए record के ज़्यादा क़रीब है, और Zig अभी 1.0 नहीं है
    PR में पर्याप्त context और rationale मौजूद है
    Zig चुनते समय आपने एक हद तक language change risk स्वीकार ही किया है
    बल्कि इस चरण में चीज़ों को साफ़-सुथरा करना लंबे समय में फ़ायदेमंद है
    (C के bitwise operator precedence जैसी ऐसी विरासतों को याद कीजिए जिन्हें बाद में ठीक नहीं किया जा सकता)
  • mlugg Zig के core contributor और Zig Foundation के सदस्य हैं
    यह बदलाव circular dependency को सुलझाने और type system को व्यवस्थित करने के लिए है
    संबंधित प्रस्ताव #3257 और #15909 में खुले रूप से मौजूद हैं
    इस बदलाव से Zig का type resolution DAG(Directed Acyclic Graph) संरचना में व्यवस्थित हो जाता है, जिससे compiler stability काफ़ी बेहतर होती है
    Zig को BDFN(Benevolent Dictator For Now) model पर चलाया जाता है, और अंतिम निर्णय Andrew Kelley के पास है
    लेकिन टीम एक non-profit organization के रूप में user trust और language quality को सबसे ऊपर रखती है
    निजी तौर पर Matthew के साथ काम करना मेरे लिए बड़े सम्मान की बात है
  • शायद यह रवैया C language के अव्यवस्थित इतिहास को एक चेतावनी की तरह देखने का नतीजा भी हो सकता है
    औपचारिक रूप से परिष्कृत होने के बावजूद, व्यवहार में अराजक भाषा रहे C की याद दिलाता है