Zig – io_uring और Grand Central Dispatch std.Io इम्प्लीमेंटेशन जोड़े गए

 (ziglang.org)
2 पॉइंट द्वारा GN⁺ 2026-02-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Zig standard library के std.Io.Evented मॉड्यूल में io_uring और Grand Central Dispatch(GCD) आधारित इम्प्लीमेंटेशन नए सिरे से एकीकृत किए गए हैं
  • दोनों इम्प्लीमेंटेशन user-space stack switching (fibers, stackful coroutines, green threads) तरीके से काम करते हैं
  • अभी यह experimental stage में है, और error handling सुधार, logging हटाना, performance degradation के कारणों का विश्लेषण, test strengthening जैसे आगे के काम जरूरी हैं
  • एक ही application code में सिर्फ I/O backend बदलकर io_uring या GCD के बीच आसानी से स्विच किया जा सकता है
  • Zig compiler में भी दोनों इम्प्लीमेंटेशन काम करते हैं, और भविष्य में स्थिर होने पर यह platform-specific async I/O integration foundation के रूप में विकसित हो सकते हैं

io_uring और GCD आधारित std.Io.Evented इम्प्लीमेंटेशन

  • Zig 0.16.0 release cycle के अंत में std.Io.Evented को नवीनतम API बदलावों के अनुसार अपडेट किया गया

    • नए जोड़े गए इम्प्लीमेंटेशन हैं io_uring (Linux) और Grand Central Dispatch(GCD) (macOS)
    • दोनों इम्प्लीमेंटेशन user-space stack switching (fibers, stackful coroutines, green threads) तकनीक का उपयोग करते हैं

  • दोनों इम्प्लीमेंटेशन अभी experimental state में हैं, और स्थिर उपयोग के लिए कई सुधार कार्य बाकी हैं

    • error handling सुधार की जरूरत
    • logging हटाने और performance degradation के कारणों की पहचान की जरूरत (IoMode.evented उपयोग करने पर compiler performance degradation होता है)
    • कुछ unimplemented functions मौजूद हैं और test coverage बढ़ाने की जरूरत
    • प्रति-function maximum stack size जांचने के लिए builtin function जोड़ने की जरूरत (overcommit निष्क्रिय होने पर व्यावहारिक उपयोग सुनिश्चित करने के लिए)

I/O इम्प्लीमेंटेशन बदलने का उदाहरण

  • एक ही application code में सिर्फ I/O backend बदलकर इसे चलाया जा सकता है

    • उदाहरण code में std.Io.Threaded की जगह std.Io.Evented इस्तेमाल करने पर यह io_uring आधारित रूप में चलता है
    • app function वही रहता है, और output result (Hello, World!) भी समान रहता है

  • strace result की तुलना से दोनों execution methods का अंतर देखा जा सकता है

    • hello_threaded सामान्य thread-based I/O calls का उपयोग करता है
    • hello_evented io_uring system calls (io_uring_setup, io_uring_enter आदि) का उपयोग करता है

Zig compiler में लागू होना और वर्तमान स्थिति

  • Zig compiler स्वयं भी std.Io.Evented का उपयोग करके सही तरह काम करता है

    • compiler को io_uring और GCD दोनों पर चलाया जा सकता है
    • लेकिन performance degradation का कारण अभी स्पष्ट नहीं है, इसलिए आगे विश्लेषण की जरूरत है

  • इस बदलाव से Zig code I/O इम्प्लीमेंटेशन को आसानी से बदल सकने वाली संरचना के और करीब पहुंचता है

    • इससे platform-specific async I/O models को एकीकृत तरीके से संभालने की नींव बनती है

आगे के कार्य

  • स्थिर उपयोग के लिए performance improvement और test strengthening की जरूरत
  • stack size management feature जुड़ने पर, overcommit निष्क्रिय वातावरण में भी इसका व्यावहारिक उपयोग संभव होगा
  • पूरा होने पर Zig की async I/O abstraction layer और मजबूत होने की संभावना है

निष्कर्ष

  • यह अपडेट Zig के standard I/O system expansion में एक महत्वपूर्ण प्रगति है
  • io_uring और GCD को एकीकृत करके platforms के बीच async processing consistency सुनिश्चित करने की आधारशिला रखी गई है
  • भविष्य में stabilization work पूरा होने पर Zig के high-performance और flexible I/O model की संभावनाएं और बढ़ेंगी

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

1 टिप्पणियां

 
GN⁺ 2026-02-15
Hacker News की राय

  • मैं Zig का प्रशंसक नहीं हूँ, लेकिन एक छोटी टीम को लगातार आगे बढ़ते देखना अच्छा लगता है
    पूरा कर देने से ज़्यादा प्रयोग और क्रमिक सुधार को महत्व देने वाला रवैया प्रभावशाली है
    1.0 को जल्दबाज़ी में जारी करने के बजाय दीर्घकालिक लक्ष्यों की ओर बढ़ना ज़्यादा महत्वपूर्ण लगता है
    एक व्यक्ति-केंद्रित प्रोजेक्ट के लिए यह चौंकाने वाली उपलब्धि है, और मेहनत करने वालों को उचित मान्यता मिलनी चाहिए

    • मैं हर बार कोई नई भाषा सीखते समय TCP/UDP मल्टीप्लेयर सर्वर वाला गेम इंजन बनाकर देखता हूँ, और हाल में Zig के साथ कोशिश की
      अब तक का यह सबसे मज़ेदार और उत्पादक अनुभव था
      Rust की सख्त मेमोरी मैनेजमेंट की तुलना में Zig की सादगी मेरे लिए कहीं बेहतर बैठती है
      ज़िंदगी छोटी है, और मैं बस तेज़ और अच्छी तरह व्यवस्थित software बनाना चाहता हूँ

  • Zig पर हर लेख में बहुत आलोचना होती है, लेकिन लोग इतना क्यों परवाह करते हैं, यह समझ नहीं आता
    Andrew और टीम जिस बात पर विश्वास करती है उसे साकार करने की engineering spirit ही उल्टा प्रेरणादायक लगती है
    Zig मुख्यधारा बनेगा या नहीं, इसकी चिंता करने की ज़रूरत नहीं; अगर यह समस्या हल करने में मदद करता है, तो वही काफ़ी है
    भाषा को अपनी पहचान की तरह लेने की ज़रूरत नहीं है

    • इस तरह की स्थिति खत्म करनी है तो प्रोग्रामरों को मिलने वाले आर्थिक प्रोत्साहन बदलने होंगे
      भाषाएँ और लाइब्रेरी आखिरकार ‘बेची जा सकने वाली skills’ हैं, इसलिए लोग अपने इस्तेमाल के tools की बाज़ार-योग्यता को लेकर सचेत रहते हैं
      इसके अलावा, निर्णय लेने वाले लोग engineers को बदले जा सकने वाले asset की तरह देखते हैं, यह भी समस्या है
    • ऐसी language debates सिर्फ Zig तक सीमित नहीं हैं
      Lisp, Ruby, Rust आदि में भी यह दोहराया गया है, और पहचान की लड़ाई उद्योग की पुरानी समस्या है
    • नया language stack Linux distributions में maintenance burden बढ़ाता है
      security, architecture support जैसी चीज़ों के लिए लंबे समय तक देखभाल चाहिए, फिर भी developers अक्सर उसकी लागत को नज़रअंदाज़ करते हैं
      Zig अभी स्थिर नहीं है, इसलिए packages सिर्फ कुछ खास versions पर ही compile होते हैं
      जिन समस्याओं को दूसरी भाषाओं में सुधार करके हल किया जा सकता है, क्या उनके लिए सचमुच नई भाषा चाहिए — इस पर संदेह है
    • मुख्यधारा की भाषा बनने के लिए ज़्यादातर use cases को कवर करने वाला अनुमानित library ecosystem चाहिए

  • Zig 1.0 बनने तक उसे follow करने का कोई खास मतलब नहीं लगता
    मौजूदा संरचना कई बार फिर से लिखी जा सकती है
    मुझे भी कभी इसमें रुचि थी, लेकिन अपने जीवनकाल में 1.0 देख पाऊँगा या नहीं, पता नहीं

    • वास्तव में Zig में compatibility breakage ज़्यादातर standard library (stdlib) में होता है
      file I/O जैसी बुनियादी चीज़ें लगभग वही रहती हैं, बस namespace बदलते हैं
      मुझे ‘living language’ ज़्यादा बेहतर लगती है
      1.x के बाद भी stdlib को slim रखने के लिए version-wise interface management strategy होनी चाहिए
    • Zig भाषा खुद मुझे पसंद है, लेकिन stdlib की गुणवत्ता पर सवाल उठते हैं
      I/O framework खुद बनाते समय मुझे testing की कमी और गलत assembly code मिला
      कई बार बताने के बाद भी यह ठीक नहीं हुआ, इसलिए भरोसा कम हुआ
    • बड़े प्रोजेक्ट्स के लिए हिचक हो सकती है, लेकिन Zig में पहले से व्यावसायिक मूल्य है
      खासकर cloud environments में performance optimization के ज़रिए server cost को 90% से ज़्यादा घटाया जा सकता है
      Python या Node के साथ एक सीमा आती है, इसलिए अंततः C, C++, Rust, Zig में से किसी एक पर नीचे आना पड़ता है
      उनमें Zig सीखना आसान है, और पढ़ने व test करने में सुविधाजनक है
    • संदर्भ के लिए, Bun भी Zig में लिखा गया है
      यह पहले से वास्तविक कामकाजी स्तर पर इस्तेमाल हो रही भाषा है
    • हमारी टीम (ZML) std.Io आने के बाद से लगातार Zig master branch को follow कर रही है
      अधिकांश बदलाव सचमुच भाषा में सुधार जैसे लगते हैं

  • यह दिलचस्प है कि Rust में io_uring support अभी पूरा नहीं हुआ, जबकि Zig ने पहले implementation की कोशिश की
    Rust में सुरक्षित और zero-cost abstraction डिज़ाइन करना कठिन है

  • यह खबर अभी अधूरी implementation के बारे में है
    उदाहरण के लिए GCD version में networking नहीं है
    interface लगातार बड़ा हो रहा है, इसलिए इसे पूर्ण रूप से तैयार चीज़ से ज़्यादा मौजूदा snapshot कहना सही होगा

    • लेकिन लेख की शुरुआत में ही इसे experimental stage बताया गया था,
      और आगे किए जाने वाले 6 बड़े कार्यों को भी स्पष्ट रूप से सूचीबद्ध किया गया था

  • stack memory optimization से जुड़ा एक issue है
    अलग-अलग blocks में [500]u8 इस्तेमाल करने पर भी stack frame में सिर्फ 500 bytes ही लगें, ऐसी सुविधा चाहिए
    यह खास तौर पर green thread coroutine stacks के संदर्भ में महत्वपूर्ण है

  • मैं Zig के लगातार सुधार के प्रयासों को सकारात्मक रूप से देखता हूँ
    इस समय कोई भी भाषा io_uring को ठीक से नहीं संभालती
    अगर Zig इस हिस्से को अच्छी तरह हल कर लेता है, तो उसे बड़ा बढ़त मिल सकता है
    स्थिरता से ज़्यादा सीखने और प्रयोग को महत्व देना अधिक मूल्यवान लगता है

    • यह दिलचस्प है कि लोग low-level language में भी async चाहते हैं
      मैं Zig में libxev का उपयोग करके io_uring को सीधे नियंत्रित करना पसंद करता हूँ
    • मैं भी सकारात्मक हूँ, लेकिन यह जानने की उत्सुकता है कि Zig कब C की तरह long-term stable version (LTS) देगा
      C की सफलता का एक कारण उसकी स्थिरता और सुसंगत development culture था

  • यह अच्छा लगता है कि Zig freestanding targets को गंभीरता से लेता है
    उम्मीद है कि 0.16 version में code reusability और बेहतर होगी

  • मैंने काफ़ी समय बाद macOS के अंदरूनी हिस्सों को देखा, और GCD को बनाए रखना अच्छा लगा
    यह parallelization के लिए संतुलित दृष्टिकोण जैसा लगता है

  • जब दूसरी भाषाएँ सिर्फ बहस कर रही हैं, Zig खुद कोशिश करता है, और ज़रूरत पड़े तो पीछे भी हट जाता है
    मेरा मानना है कि वास्तविक उपयोग में परखा गया API ही सबसे अच्छा डिज़ाइन होता है
    पुराने versions को बनाए रखा जा सकता है, और नए version पर जाने से ज़्यादा साफ़ और तेज़ tools मिल सकते हैं

    • Jai गेम development केंद्रित है, इसलिए general-purpose उपयोग या safety के मामले में कमज़ोर है
      वह C++ की तरह जटिल है, जबकि Zig C-स्तर की सादगी बनाए रखता है
      Carbon अभी भी ठोस रूप नहीं ले पाया है
    • Zig के 1.0 न होने की आलोचना अजीब लगती है
      Jai 11 साल से closed beta में है, जबकि Zig पहले से कई वास्तविक प्रोजेक्ट्स में इस्तेमाल हो रहा है
    • मुझे लगता है कि किसी भाषा को 20 साल भी लगें, तो भी उसका सही तरीके से पूरा होना बेहतर है
      Python 2→3, Rust async, Go generics, C++ आदि में देखे गए बेतरतीब बदलाव उल्टा नुकसानदेह हो सकते हैं