फिर से Zig की ओर लौटना - Zig → Rust → Zig

• Zig एक low-level भाषा के रूप में शुरू हुई थी जो C की असुविधाओं को कम करना चाहती थी, और स्पष्ट memory allocation तथा hidden control flow न होने जैसे सिद्धांतों के कारण यह फिर से गंभीरता से देखने लायक भाषा बन गई है
• Rust, Zig के बार-बार बदलने और अपरिपक्व ecosystem से निकलने का एक व्यावहारिक विकल्प था, लेकिन FFI, cross-compilation और hidden allocation जैसे बिंदुओं पर इसकी सीमाएँ सामने आईं
• Zig पर लौटने के फैसले में सिर्फ तकनीकी कारण ही नहीं थे; governance और LLM-generated code policy को लेकर Rust project पर भरोसा कम होना भी एक कारण था
• 2026 का Zig अब भी अस्थिर है और Zig 0.17.0 build system को तोड़ने वाला है, लेकिन भाषा का अनुभव 2020 से बहुत अलग नहीं है और package management का अनुभव बेहतर हुआ है
• Zig, Rust जैसी compile-time memory safety नहीं देता; इसके बदले वह ReleaseSafe, tests, fuzzing और assertion की philosophy के ज़रिए सादगी और runtime safety के बीच संतुलन चुनता है

---

Zig की ओर शुरुआती आकर्षण

• Zig से पहली बार 2020 में सामना हुआ, और उस समय यह compile-time code execution और सरल abstractions वाली एक छोटी नई भाषा जैसा लगा
• C सीखते समय कंप्यूटर को सीधे नियंत्रित करने का एहसास अच्छा था, लेकिन पुराने abstractions और कमज़ोर tooling असुविधाजनक थे
• नया और अस्थिर होने के बावजूद Zig, C के replacement language होने का वादा करता था, और “अगली भाषा” सीख सकने का आकर्षण भी था
• Andrew Kelley का Software Should Be Perfect प्रोग्रामिंग भाषाओं और software को देखने का एक मानदंड बना
  • असफल हो सकने वाला स्पष्ट memory allocation
  • hidden control flow नहीं
  • universal reusability
• Zig में toy programming language, literate programming tool और web server बनाते हुए यह C से अधिक सुविधाजनक लेकिन कम जोखिम वाली भाषा जैसी लगी

Rust की ओर जाने के कारण

• Zig में code बार-बार टूट जाता था, और छात्र जीवन में नए language version के मुताबिक projects को लगातार ठीक करते रहना संभव नहीं था
• उस समय anyzig नहीं था, इसलिए एक ही system पर कई Zig versions को आसानी से संभालना मुश्किल था
• कुछ महीनों बाद project पर लौटने पर, उसे फिर से चलाने के लिए ऐसे बड़े refactoring करने पड़ते थे जिन्हें ठीक से समझा भी नहीं गया होता था
• ecosystem भी अभी छोटा था
  • नए programmer के रूप में ज़रूरी हर चीज़ खुद implement करने की क्षमता नहीं थी
  • libraries और examples कम थे
  • standard library लगातार बदल रही थी
  • बुनियादी documentation भी अस्थिर थी
• Rust तब तक कई सालों से stable हो चुका था और उसके पास मज़बूत ecosystem था
• Rust सीखना कठिन था, लेकिन एक बार सीख लेने के बाद code स्थिर रूप से काम करता था, और यह स्थिरता महत्वपूर्ण थी
• यह तेज़ और low-level भाषा होते हुए भी ज़रूरी expressiveness देती थी, और Zig में झेली जा रही instability की लागत भी कम करती थी
• Rust ने ऐसी memory model समझ विकसित करने में मदद की जो कम built-in checks वाली भाषा इस्तेमाल करते समय भी काम आती है
• panic के बिना code में hidden control flow या garbage collector के बिना reusable code लिखा जा सकता था
• लेकिन Rust में memory allocation छिप जाने और C के साथ काम कठिन होने जैसी समस्याएँ भी थीं

वे असंतोष जिनसे Zig की ओर फिर देखना पड़ा

• Rust, मनचाहे reusable programs बनाने के लिए परिपूर्ण भाषा नहीं थी
  • FFI कठिन है
  • cross-compilation झंझटभरा है
  • hidden memory allocation, जिन्हें असफल न होने वाला मान लिया जाता है, बोझिल लगते हैं
  • LLVM से बँधा होने के कारण, C जितने platform support तक पहुँचना बहुत लंबा समय ले सकता है या संभव ही न हो
• governance भी असुविधा का कारण बना रहा
  • Rust Foundation में कई बड़ी कंपनियाँ foundation members के रूप में शामिल हैं
  • दुनिया की सबसे बड़ी कंपनियों से हर साल लाखों डॉलर आने पर Rust के विकास की दिशा प्रभावित हो सकती है, ऐसा माना गया
• open source समुदाय में LLM-generated code स्वीकार करने वाले projects बढ़ना एक झटका था
• कई projects में maintainers और users ने LLM policies लिखीं या उनकी माँग की
• Zig ने project में LLM को पूरी तरह प्रतिबंधित किया है
• Rust ने survey चलाया और community का समग्र रुझान anti-LLM था, लेकिन उसने तुरंत कोई आधिकारिक policy नहीं बनाई
• Rust की policy proposal में PR comments में निम्न विषयों का उल्लेख न करने वाला प्रावधान शामिल था
  • LLM के दीर्घकालिक सामाजिक और आर्थिक प्रभाव
  • LLM का पर्यावरणीय प्रभाव
  • LLM outputs की copyright स्थिति
  • LLM users पर नैतिक निर्णय
• बाद में विरोध के बाद वह प्रावधान हटा दिया गया, लेकिन उसके अस्तित्व मात्र से Rust project पर भरोसा कम हो गया
• policy खुद अधिकतर LLM को सीमित करने और slop कम करने पर केंद्रित थी, इसलिए उसे ठीक माना गया
• इसी अनुभव ने कई सालों बाद Zig को फिर गंभीरता से देखने का अवसर दिया

2026 का Zig

• Zig अब भी अस्थिर है
• वेब पर मिले Zig 0.16.0 examples से शुरू करने की कोशिश की गई, लेकिन वे पहले ही पुराने हो चुके थे
• Zig में productive ढंग से काम करने के लिए standard library source की एक प्रति पास रखना और उससे परिचित होना सबसे अच्छा है
• Zig 0.17.0 जल्द release होने वाला है और सभी projects के build system को तोड़ने वाला है
• maintainers stabilization की ओर बढ़ना चाहते हैं, और इस तरह के breakages उसी प्रक्रिया का हिस्सा हैं
• अच्छी बात यह है कि 2020 के बाद भाषा स्वयं बहुत नहीं बदली है
  • ज़्यादातर intuitions अब भी काम करती हैं
  • library के कुछ हिस्से दोबारा बनाए गए हैं, लेकिन code पढ़ने में आसान है
  • मौजूदा Zig code भी 6 साल बाद पहचाना जा सकेगा, ऐसा लगता है
• अब Zig में package manager है
  • पहले dependency management के लिए git submodule इस्तेमाल करने की याद है
  • built-in tooling कहीं बेहतर है
  • project, git और tarball के ज़रिए dependencies परिभाषित कर सकते हैं
  • vendoring आसानी से काम करता है
• ecosystem अब भी बहुत विशाल नहीं है, लेकिन Zig का लक्ष्य भी विशाल ecosystem बनना नहीं था
• कोई आधिकारिक package registry नहीं है, और रुख यह है कि एक और NPM या crates.io की ज़रूरत नहीं है
• मौजूदा Zig को सही संतुलन पर पहुँचा हुआ माना गया है

memory safety को देखने का तरीका

• Zig, Rust जैसी memory safety guarantees नहीं देता
• यह सादगी के लिए किया गया trade-off है, और यह माना गया कि Rust के affine types की जटिलता, सुरक्षा से मिलने वाले लाभ के बराबर मूल्यवान नहीं है
• इसका मतलब यह नहीं कि Zig ने safety छोड़ दी है
• Zig is safer than unsafe Rust वाले दृष्टिकोण के अनुसार, जिन स्थितियों में unsafe Rust लिखना पड़ता है वहाँ Zig बेहतर विकल्प हो सकता है
• Zig भाषा को और सुरक्षित बनाने का काम भी जारी है
  • इसका दृष्टिकोण unsafe code regions पर नहीं बल्कि release mode पर केंद्रित है
  • फिलहाल Zig का ReleaseSafe mode assertion failure पर crash करता है और सारी memory initialize करता है
  • Andrew Kelley, ReleaseSafe में Fil-C जैसी चीज़ शामिल करने की दिशा में रुचि रखते हैं
• यह तरीका unsafe से बचने वाले Rust की compile-time memory safety नहीं देता, लेकिन कुछ लोगों के कहे अनुसार यह कोई death spiral भी नहीं है
• memory safety एक spectrum है, और हर स्थिति के लिए एक ही सर्वोत्तम तरीका नहीं होता
• Zig का तरीका यह है कि ReleaseSafe को runtime पर जितना संभव हो उतना सुरक्षित बनाया जाए, और tests व fuzzing से correctness की पुष्टि की जाए
• unchecked illegal behavior को इसी प्रक्रिया में ढूँढ़ना चाहिए, और correctness सिद्ध हो जाने के बाद दूसरे release modes की binaries को सुरक्षित रूप से ship किया जा सकता है
• Rust model की तुलना में इस तरीके की कमियाँ हैं, लेकिन सादगी को बहुत गंभीरता से लेने वाली Zig की दिशा में इसे सख्ती से निम्नतर नहीं माना गया
• अगर compile-time memory safety इतनी महत्वपूर्ण है कि उसके लिए जटिल type system और लंबा compile time स्वीकार हो, तो Rust चुना जा सकता है
• Zig का memory safety model assertion philosophy तक भी फैलता है
  • ReleaseFast में assertions बंद करने के बजाय, यह भरोसा किया जाता है कि tests के ज़रिए assertions के सही होने और उस path के unreachable होने को सिद्ध किया गया है
  • इससे Zig code को optimize कर सकता है
  • संबंधित लेख है your assertions are correct

आगे के उपयोग की दिशा

• standard library और release changelog को साथ रखकर Zig में software problems पर काम करने की तैयारी हो चुकी है
• जब low-level details से नहीं जूझना होगा, तब पसंदीदा scripting language का उपयोग किया जाएगा
• आगे के software में Zig को मुख्य tool के रूप में इस्तेमाल करने की योजना है
• Zig पर हमेशा बने रहने की संभावना निश्चित नहीं मानी गई है
  • Rust की stability या type system की ज़रूरत हो तो Rust इस्तेमाल किया जा सकता है
  • Zig के approach को लेकर विचार पूरी तरह बदल भी सकते हैं
  • कई भाषाएँ साथ रह सकती हैं, और रहनी भी चाहिए
• Zig, software quality की अनदेखी किए बिना उसे स्वीकार करके user-केंद्रित software vision का प्रतिनिधित्व करता है
• लोगों को भरोसेमंद और शक्तिशाली software मिलना चाहिए, और LLM युग में ऐसा माना गया कि ध्यान से बनाया गया software दुर्लभ होता जा रहा है और लोगों पर बदतर होते slop को स्वीकार करने का दबाव डाला जा रहा है

[clastneo]

Zig सीखते समय मैंने सुना कि नया version आने वाला है, और उसी वजह से सीखना छोड़ दिया था।
Stable version आ जाए तो इसे फिर से अपनी learning list में डालने लायक होगा, लेकिन अभी तक breaking changes इतने ज़्यादा हैं कि हाथ लगाने में डर लगता है।

[click]

Zig भाषा spec बदलते हुए बार-बार backward compatibility छोड़ देती है; ऐसे में मुझे लगता है कि कम-से-कम 1.0 आने तक इसे महत्वपूर्ण systems में इस्तेमाल करना मुश्किल है।
ghostty को std.IO में बदलाव की वजह से काफ़ी परेशानी हो रही लगती है: issue
दूसरी भाषाओं का उदाहरण लें—अगर Java में Future आने के बाद jdbc api इस तरह बदल गया होता कि वह Future या CompletableFuture return करे, तो निश्चित रूप से यह बड़ी तरक़्क़ी होती, लेकिन इसकी क़ीमत बहुत ज़्यादा confusion के रूप में चुकानी पड़ती।

[GN⁺]

Lobste.rs की रायें

• कभी न कभी Zig को फिर से आज़माना चाहता हूं
  सच में करना तो चाहता हूं, लेकिन अब तक दूसरे कामों में व्यस्त रहा हूं
  आखिरी बार जब Zig को हाथ लगाया था, तो करीब 3 घंटे में ही compiler error मिल गया था और वह काफी याद रह गया। निष्पक्ष रूप से कहें तो वह bug पहले ही latest branch में fix हो चुका था

• “LLVM से बंधा होने के कारण C जितने platform support करने में बहुत लंबा समय लगेगा, या शायद कभी नहीं हो पाएगा” वाली बात पर संदेह होता है
  जानना चाहता हूं कि LLVM जिन platforms को support नहीं करता, उनमें से किसे target करके develop करना चाहते हैं, और इस मामले में Zig कैसे बेहतर है
  पूछना चाहूंगा कि क्या मतलब यह है कि Zig tier-4 C code generate करता है, और GCC उसे hppa, alpha, sh के लिए compile कर सकता है

  • मेरी समझ के मुताबिक, Zig LLVM dependency घटाने के काम पर सक्रिय रूप से काम कर रहा है, इसलिए आगे Zig compiler में नए targets implement करते समय शायद LLVM project को ही छूने की जरूरत न पड़े—बात इसके ज्यादा करीब थी
  • अभी C code generation ही उसका implementation तरीका है
    समस्या यह है कि Zig के पास LLVM के अलावा official backend है, जबकि Rust LLVM इस्तेमाल करता है
    अगर कोई systems language software reusability को अधिकतम करना चाहती है, तो उसे जितना संभव हो उतनी व्यापक जगहों पर चलना चाहिए; और अगर उसका इरादा Zig की तरह C को replace करने का है, तो यह खास तौर पर सही लगता है
  • धुंधली याद के हिसाब से, चिंता का केंद्र platform support से ज्यादा compile time की तरफ था

• ghostty की सफलता देखकर, Zig के 1.0 तक पहुंचने पर उसे game development में इस्तेमाल करने की योजना है
  हालांकि मैं जिस तरह के games बनाता हूं, उनके लिए सच में इतनी performance चाहिए या नहीं, यह पक्का नहीं है

  • अगर आप Godot जानते हैं, तो https://github.com/godot-zig/godot-zig आज़मा सकते हैं

• “Zig ने safety छोड़ी नहीं है, और वह unsafe Rust से ज्यादा safe है। वैसे भी अगर unsafe Rust इस्तेमाल करना ही पड़े, तो Zig बेहतर हो सकता है” जैसी बातें काफी आम हैं, लेकिन हर बार देखने पर समझ नहीं आतीं
  खासकर यह अजीब लगता है कि लेखक safety एक spectrum है यह मानते हुए भी, local unsafe regions इस्तेमाल करने के बजाय ऐसी भाषा पर जाने की सलाह देता है जिसमें सब कुछ लगातार unsafe है
  abstract machine पर reasoning करना थोड़ा आसान हो सकता है, लेकिन यह trade-off मुझे समझ में नहीं आता