डिबग मोड में self-hosted x86 backend अब डिफ़ॉल्ट है

• अब x86_64 target पर, Zig का self-hosted x86 backend डिबग मोड में डिफ़ॉल्ट रूप से लागू होता है
• मौजूदा LLVM-आधारित तरीके की तुलना में इसने अधिक behavior tests पास किए हैं और compile speed भी तेज़ हासिल की है
• self-hosted backend अपनाने से Zig के compile time में बड़ी कमी आई है और कुछ कार्यों की दक्षता बढ़ी है
• हाल में build system में सुधार, BSD परिवार के OS support का विस्तार, UBSan runtime में सुधार सहित कई फीचर मज़बूत किए गए हैं
• standard library और self-hosted tools optimization के ज़रिए Zig की अलग प्रतिस्पर्धी क्षमता को रेखांकित किया गया है

---

हाल की प्रमुख ख़बरों का सार

8 जून 2025 – self-hosted x86 backend डिबग मोड में डिफ़ॉल्ट में बदला

• x86_64 target पर अब डिफ़ॉल्ट रूप से Zig का self-hosted x86 backend इस्तेमाल होता है
  • पहले LLVM का उपयोग करके bitcode को object file में बदला जाता था
  • Windows में COFF linker पर और काम की ज़रूरत होने के कारण यह बदलाव अभी टाला गया है
• Zig का x86 backend 1,987 behavior tests पास कर चुका है, जो LLVM backend (1,980) की तुलना में अधिक मज़बूत स्थिरता दिखाता है
  • कुल टेस्ट 2,084 हैं, लेकिन उनमें से कुछ LLVM के अपने tests के साथ duplicate हैं, इसलिए self-hosted backend testing के समय ही अतिरिक्त रूप से जाँचे जाते हैं
• Zig के अपने code generator के विकास पर ध्यान देने का मुख्य कारण build speed में LLVM को स्पष्ट रूप से पीछे छोड़ना है
  • benchmark के अनुसार, zig build-exe hello.zig -fllvm (LLVM उपयोग) का औसत build time 918ms था, जबकि self-hosted backend ने 275ms दर्ज किया
  • memory usage, CPU cycles, instruction count, cache misses सहित हर पहलू में काफ़ी बेहतर performance देखी जा सकती है
  • Zig compiler जैसे बड़े project का build time भी 75 सेकंड से घटकर 20 सेकंड हो गया है
• आगे code generation की पूर्ण parallelization, linking features को मज़बूत करना, और aarch64 backend development की योजना है
  • नए Legalize pass के आने से aarch64 पर काम भी तेज़ होने की उम्मीद है
• नवीनतम बदलावों का अनुभव Zig master branch के latest build के ज़रिए सीधे किया जा सकता है

6 जून 2025 – build system परिचय वीडियो

• Zig build system सीखने वाले beginners के लिए YouTube guide video जारी किया गया है
  • इसमें Zig modules और packages बनाना, और उन्हें दूसरे projects में import करना समझाया गया है
  • build system से जुड़े अतिरिक्त वीडियो भी आगे series के रूप में जोड़े जाने वाले हैं

20 मई 2025 – FreeBSD और NetBSD target support मज़बूत हुआ

• Pull Request #23835, #23913 के merge होने से zig cc और zig build के साथ FreeBSD 14.0.0+ और NetBSD 10.1+ targets के लिए binary build करना संभव हो गया है
  • पहले glibc पर लागू की गई libc और संबंधित libraries की जानकारी extract करने की रणनीति अब BSD परिवार पर भी विस्तारित की गई है
  • बने हुए abilists files Zig के साथ distribute किए जाते हैं, जिससे cross compilation के दौरान हर libc library से सटीक मेल खाने वाली stub libraries बनाई जा सकती हैं
  • system और libc headers भी नवीनतम OS version के आधार पर साथ में उपलब्ध कराए जाते हैं
  • OpenBSD, Dragonfly BSD, SerenityOS, Android, Fuchsia आदि भी support targets में शामिल हैं

9 अप्रैल 2025 – आधिकारिक Zig साइट अब standalone Zine के रूप में build होती है

• आधिकारिक Zig website की संरचना अब standalone Zine के रूप में build होने के लिए बदल दी गई है
  • यह मौजूदा build script से आगे बढ़कर एक single executable में विकसित हुई है
  • इसे सीधे आज़माने के लिए अच्छा समय बताया गया है

release और feature improvements

• 0.14.0 release जल्द जारी होने वाली है, और कई उल्लेखनीय सुधार पहले ही लागू किए जा चुके हैं
• C interop और UBSan (Undefined Behavior Sanitizer) runtime में सुधार के चलते, पहले अस्पष्ट रहने वाली SIGILL errors अब अधिक स्पष्ट और उपयोगी error messages से बदली गई हैं
  • उदाहरण: signed integer overflow कहाँ और क्यों हुआ, यह स्पष्ट रूप से दिखाया जाता है, जिससे debugging efficiency काफ़ी बढ़ती है
• UBSan की बची हुई सीमाएँ:
  • C++ vptr से जुड़े dynamic type और lifecycle checks का support नहीं है
  • assume_aligned, __nonnull जैसे attributes की सटीक location दिखाना अभी अधूरा है

7 फ़रवरी 2025 – debug allocator और SmpAllocator में नवाचार

• debug allocator को फिर से डिज़ाइन किया गया है, जिससे runtime page size awareness और कई optimizations शामिल हुए हैं
  • memory map creation में कमी, अनावश्यक 0xaa/0x00 memset दोहराव हटाना, search और trip data structures हटाना आदि शामिल हैं
  • metadata को page के भीतर inline तरीके से store किया जाता है, जिससे compile errors/validation को आसान बनाया गया है
  • मौजूदा C-आधारित malloc की तुलना में readability और maintainability में बढ़त हासिल की गई है
• concurrency environments के लिए optimize किया गया SmpAllocator विकसित किया गया है, जिससे multi-thread environment में memory allocation की execution efficiency अधिकतम हुई है
  • glibc के साथ performance benchmark तुलना में speed और resource usage efficiency वास्तव में साबित हुई है
  • नतीजतन, इसे Zig usability के C और libc से आगे निकलने वाले एक अहम मोड़ के रूप में देखा जा रहा है

24 जनवरी 2025 – Zig के लिए समर्पित debugging environment

• Jacob ने Zig के लिए LLDB (debugger) का fork विकसित किया है, जिससे self-hosted backend की debugging support और मज़बूत हुई है
  • LLDB fork को build और उपयोग करने का तरीका wiki documents में दिया गया है
  • Zig के self-hosted backend का उपयोग करने वाले developers अब इस tool के साथ अधिक परिष्कृत debugging environment का लाभ उठा सकते हैं

निष्कर्ष

• Zig अपने आधारभूत ढाँचे में performance improvement, build efficiency, और debugging convenience को मुख्य लक्ष्य बनाकर लगातार बड़े बदलाव आगे बढ़ा रहा है
• स्वतंत्र algorithms, compiler, और build/runtime tools सभी में यह अलग प्रतिस्पर्धी बढ़त बना रहा है
• BSD सहित कई platforms support, user-centric messages में सुधार, और memory model innovation के साथ यह software engineers के लिए व्यावहारिक रूप से उपयोगी प्रगति जारी रखे हुए है

[GN⁺]

Hacker News राय

• मेरी समझ के मुताबिक Zig डेवलपमेंट अनुभव को बेहतर बनाने के लिए हर दिन अलग-अलग फीचर्स पर काम कर रहा है। उदाहरण के लिए हाल ही में यह PR भी आया था। पहले Zig में hot code swapping भी डेवलपमेंट प्लान का हिस्सा था, और इस रफ्तार से देखें तो शायद 1 साल के भीतर x86_64 पर यह फीचर संभव हो जाएगा। व्यक्तिगत रूप से मुझे सबसे बड़ी असुविधा comptime की स्पीड लगती है। मैंने compile time पर brainF** DSL चलाने का एक प्रयोग किया था, और वह वाकई बहुत धीमा चला (हालांकि प्रयोग मजेदार था)। सोचता हूँ कि compiler के इस हिस्से में सुधार कब तक होगा। नए backends को लेकर भी काफी उत्साहित हूँ, और Zig के लिए अपना URCL backend भी बनाना चाहता हूँ 😉

  • comptime performance सुधार के बारे में क्या करना है, यह पहले से पता है, और बहुत पहले उससे जुड़ी एक branch भी शुरू की थी। लेकिन इसके लिए semantic analysis code को meaningful scale पर दोबारा काम करना पड़ेगा, इसलिए यह महत्वपूर्ण कामों में से एक होने के बावजूद दूसरी priorities से प्रतिस्पर्धा कर रहा है

  • hot code swapping गेम डेवलपमेंट में बहुत बड़ा बदलाव ला सकता है। Zig में इसका सिर्फ compiler flag के जरिए native support मिलना है, यह बात चौंकाने वाली लगती है। clang में तो ऐसी कोशिश करना भी मुश्किल है

  • मैंने URCL को गहराई से नहीं देखा, लेकिन यह मुझे एक और rabbit hole में ले जा रहा है। यह सोचने पर मजबूर करता है कि Minecraft के लिए बना IR कहीं किसी भाषा का असली compilation target बनने वाला कोई सचमुच अजीब परिदृश्य न बना दे

  • सोच रहा हूँ कि custom backend बनाना कितना आसान है। अभी खुद कोशिश नहीं की, लेकिन AIR लेकर memory safety report बनाने वाला backend experiment करना चाहता हूँ (जैसे undefined value use, stack pointer escape, use-after-free, double free, alias xor mut वगैरह check करने के लिए)

  • क्या comptime का सचमुच धीमा होना ही समस्या है, इस पर भी सवाल है। मैं एक JSON-RPC library बना रहा हूँ, जिसमें compile time पर comptime का खूब उपयोग करके JSON को arbitrary functions में dispatch कर रहा हूँ। Zig के मजबूत static types के कारण runtime पर arbitrary parameters वाले functions में dynamic dispatch करना संभव नहीं था, इसलिए compile time पर function type mapping बनानी पड़ी। इससे चिंता यह है कि हर function के लिए comptimed code कॉपी होगा और binary size बढ़ना तय है

• सिर्फ यहाँ तक पहुँच जाना भी अपने आप में बड़ी उपलब्धि है। devlog में जैसा कहा गया, आगे का समय और भी रोमांचक लगता है। build के दौरान compiler का binary के सिर्फ जरूरी हिस्सों को बदलना एक ताज़ा और क्रांतिकारी विचार लगता है, और Zig प्रोजेक्ट की वजह से अब यह एक हासिल किया जा सकने वाला लक्ष्य बन गया है। आगे बहुत दिलचस्प समय आने वाला है

• Zig compiler जैसे बड़े प्रोजेक्ट्स में build time 75 सेकंड से 20 सेकंड तक घटने की बात कही गई है।
  यह आगे कितना बेहतर हो सकता है, इसे लेकर मैं बहुत जिज्ञासु हूँ। Zig developers बहुत ही स्मार्ट लगते हैं।
  package management किस रूप में है, यह भी जानना चाहता हूँ। मैंने कभी QuickJS + SDL3 app Zig में बनाने की कोशिश की थी, लेकिन C++ की जटिलता के आगे हारकर आखिरकार Rust पर चला गया। Zig में फिर से कोशिश करना चाहता हूँ

  • Zig का package management Rust की तुलना में थोड़ा अधिक manual है। CLI में package URL सीधे fetch किए जाते हैं, और build script में module import किया जाता है। इस तरीके का फायदा यह है कि arbitrary archives को भी आसानी से dependency package की तरह इस्तेमाल किया जा सकता है, और Zig के लिए कई C library packages बस untouched tarball releases को build script से सीधे जोड़ते हैं। हालांकि beginners के लिए यह थोड़ा जटिल हो सकता है
    SDL3 के लिए एक native Zig wrapper (https://github.com/Gota7/zig-sdl3) है, और एक थोड़ा सरल विकल्प है जो C library/API को Zig-style में पेश करता है: https://github.com/castholm/SDL
    QuickJS के लिए केवल C API (https://github.com/allyourcodebase/quickjs-ng) supported है
    Zig में C packages को सीधे इस्तेमाल करना बहुत आसान है, लेकिन type system सख्त होने के कारण API के साथ काम करते समय type casting अक्सर करनी पड़ सकती है

  • dmd D compiler अपने debug build में खुद को लगभग 18.4 सेकंड में compile कर सकता है।
    मेरा processor बहुत पुराना AMD Athlon 64 X2(4400+) है, लेकिन यह इतना तेज़ चलता है कि मैंने अभी तक upgrade भी नहीं किया
    (CPU की विस्तृत जानकारी की सूची शामिल)

  • सोच रहा हूँ कि fast development cycle के लिए Zig को 20 सेकंड में build करने की कोई guide है क्या। पहले जब Zig build किया था, तब कई stages थीं (खासकर WASM में bootstrap), इसलिए बहुत समय लगता था

  • यह बात बहुत चौंकाने वाली है कि Zig, LLVM इस्तेमाल करते हुए भी खुद को 75 सेकंड में compile कर लेता है

• मेरा Zig से कोई अनुचित अपेक्षा रखने का इरादा नहीं है, और मैं अच्छी तरह जानता हूँ कि यह open source है, लेकिन मुझे सबसे ज़्यादा दिलचस्पी 1.0 रिलीज़ की यथार्थवादी timeline में है।
  Zig लगभग पूरी तरह वही भाषा है जिसकी मुझे low-level languages में तलाश थी, और अब मैं सिर्फ इसके stable होने का इंतज़ार कर रहा हूँ।
  और Zig की minimalist design philosophy सचमुच प्रभावित करती है

  • मेरी जानकारी में tigerbeetle जैसे वास्तविक प्रोजेक्ट्स आमतौर पर release versions pin करके इस्तेमाल करते हैं और nightly को सिर्फ experimentation के लिए रखते हैं

• एकदम beginner के तौर पर मैं जानना चाहता हूँ कि दूसरी भाषाओं की तुलना में Zig के फायदे क्या हैं। मैं इसे एक अधिक modern C के रूप में समझता हूँ, लेकिन इसमें “modern” क्या है, यही जानना चाहता हूँ

  • जो फायदे तुरंत दिमाग में आते हैं, वे कुछ इस तरह हैं
    • अलग-अलग tools और languages को जोड़ने की ज़रूरत बिना एक integrated build system
    • C arrays (buffer overflow समस्याएँ) की जगह length-aware slices
    • null pointer को default रूप से अनुमति न देने वाला साफ़ optional type (ज़रूरत हो तो type में यह explicitly दिखता है)
    • enum, tagged union, और switch statements में exhaustive checking की अनिवार्यता
    • error handling स्पष्ट है (कुछ हद तक Rust style)। अगर function error return कर सकता है, तो caller उसे अनदेखा नहीं कर सकता। C की तरह return value ignore करके आगे नहीं बढ़ सकते। हालांकि error और data को एक साथ return करने के लिए standard syntax न होना थोड़ा खलता है
    • defer, errdefer blocks के जरिए function return या error के समय automatic cleanup
    • macros की जगह comptime code generation, type reflection (@typeInfo आदि)
    • memory allocators को caller सीधे manage करता है (memory कहाँ और कैसे allocate हो, इस पर अधिक नियंत्रण)
    • GeneralPurposeAllocator इस्तेमाल करने पर (beginner के लिए) memory leak tracking कुछ आसान हो जाती है
      मैं C से परिचित नहीं था, और low-level programming में C की कई अव्यवहारिक और non-intuitive बातों के कारण हमेशा एक barrier महसूस करता था, लेकिन Zig पहली भाषा है जिसने systems programming को मेरे लिए मजेदार और रोचक बनाया

• क्या Zig को 20 सेकंड में build करने की कोई guide है? मैं development cycle तेज़ करना चाहता हूँ, लेकिन stage1/2/3 सभी build होने में बहुत समय लेते थे, इसलिए contribute करना आसान नहीं था

• अगर Zig में zig init से hello world build करने पर 9.3MB मिलता है, तो -Doptimize=ReleaseSmall flag लगाने पर यह 7.6KB तक घट जाता है
  एक ही flag से 1000x से ज़्यादा का अंतर है

  • वास्तव में उस अंतर का 82% debug information की वजह से है
    -OReleaseSmall -fno-strip पर 580KB, और -ODebug -fstrip पर 1.4MB तक मिलता है
    Zig का x86 backend Zig-specific LLDB fork के साथ कहीं बेहतर debugging experience देता है
    अभी comptime logic को debug करते समय step-through देखा जा सकता है या नहीं, यह ठीक से याद नहीं, लेकिन हाल में यह चर्चा का विषय था

• लगता है Julia performance gains पाने के लिए Zig को compiler के रूप में consider कर सकती है। हर release पर performance regression की चिंता में रहने वाले Julia developers याद आते हैं

  • Julia व्यवहार में LLVM से काफ़ी मज़बूती से बंधी हुई है। ecosystem के कई हिस्से LLVM intrinsics, autodiff (Enzyme), GPU compilation आदि पर निर्भर हैं।
    compiler धीरे-धीरे काफी retargetable बन रहा है, और इस दिशा में अभी सक्रिय research भी चल रही है।
    भविष्य में यह कल्पना की जा सकती है कि Zig भाषा के कुछ हिस्सों के लिए alternative compiler बने

  • एक राय यह भी है कि LLVM खुद Julia का public API है। वास्तव में @code_llvm जैसे macros हैं जो सीधे IR दिखाते हैं

  • compile time घटाने में निश्चित रूप से मदद मिलेगी, लेकिन Julia की तरफ अभी भी बहुत काम बाकी है
    compile cache को और granular बनाना, invalidation रोकने के लिए tooling, world splitting optimization हटाना, compiler में multithreading का अधिक उपयोग, खास signatures के लिए automatic precompilation, lazily code compile/hot swap करने जैसी चीज़ें अभी भी बाकी हैं

• यह Zig के लिए बहुत बड़ी प्रगति है, और मुझे लगता है कि Rust की तुलना में आगे चलकर यही उसका मुख्य differentiator होगा। वैसे performance analysis tool के rendering code का ज़्यादातर हिस्सा मैंने खुद लिखा था, और यह देखकर अच्छा लगता है कि मेरा code online व्यापक रूप से इस्तेमाल हो रहा है
  poop project link

  • Rust में भी cranelift का उपयोग करते हुए ऐसा ही एक प्रयास है
    rustc_codegen_cranelift देखें

• मुझे लगता है कि Zig में async/await फीचर को वापस लाने के लिए यह भी ज़रूरी पूर्वशर्तों में से एक है
  async पर Zig का official FAQ भी देखना चाहिए

  • यह हिस्सा पहले ही पूरी तरह साफ़ किया जा चुका है, और अगले 2-3 महीनों में कुछ दिलचस्प updates साझा किए जा सकेंगे। लगभग ऐसा है जैसे पूरे I/O को standard library को नए सिरे से बनाने के स्तर पर फिर से काम किया जा रहा हो

  • लिंक के मुताबिक, async शायद कभी वापस ही न आए, या कम से कम 2028 से पहले तो इसकी उम्मीद भी नहीं दिखती