Mitchell Hashimoto ने Zig Software Foundation को 3 लाख डॉलर दान देने का वचन दिया

• Mitchell Hashimoto और उनकी पत्नी ने Zig Software Foundation को 3 लाख डॉलर देने का वचन दिया है, जिससे Zig के स्वतंत्र विकास और foundation के संचालन को सार्वजनिक रूप से समर्थन मिलेगा
• दान 2 साल में हर साल 1.5 लाख डॉलर के रूप में दिया जाएगा, और पहली किस्त पहले ही भेजी जा चुकी है
• Hashimoto 2019 से Zig पर नज़र रख रहे थे, 2021 में इसे इस्तेमाल करना शुरू किया, और 2022 से इस पर लेख लिखने और compiler में योगदान देने का काम जारी रखा
• 2023 में जारी किया गया terminal project Ghostty भी Zig में लिखा गया है, और फिलहाल उनके coding time का बड़ा हिस्सा Zig में जाता है
• Zig को अभी stability और व्यापक industry adoption तक पहुँचने के लिए समय चाहिए, लेकिन Hashimoto इसे मजबूत community और sustainable funding model वाला project मानते हैं और दान करने की सलाह देते हैं

---

3 लाख डॉलर दान का वचन

• Mitchell Hashimoto और उनकी पत्नी ने Zig Software Foundation को 3 लाख डॉलर दान करने का वचन दिया है
• भुगतान 2 साल में हर साल 1.5 लाख डॉलर के रूप में किया जाएगा
  • पहली किस्त पहले ही भेजी जा चुकी है
• ZSF ने एक अलग announcement में foundation के mission और funds के具体 इस्तेमाल पर बात की है

Hashimoto Zig को क्यों support कर रहे हैं

• Hashimoto करीब 2019 से Zig project पर नज़र रख रहे थे, और 2021 में project को लेकर अपनी उम्मीदें सार्वजनिक रूप से साझा कीं
• 2021 के आखिर से उन्होंने Zig इस्तेमाल करना शुरू किया, और 2022 की शुरुआत से Zig से जुड़े लेख लिखने और compiler में योगदान देने लगे
• इसके बाद भी उन्होंने Zig repository में दर्जनों code contributions जारी रखे
• 2023 में जारी किया गया terminal project Ghostty Zig में लिखा गया है, और फिलहाल Hashimoto अपने coding time का अधिकांश हिस्सा Zig पर लगाते हैं

Zig और ZSF पर मूल्यांकन

• Hashimoto Zig को ऐसा independent software project मानते हैं जो बदलाव और प्रभाव पैदा कर सकता है
• Zig एक passion project के रूप में शुरू हुआ था और आज भी उसी प्रकृति को बनाए रखता है; वे project operations और community को मजबूत मानते हैं
• उनका मानना है कि funding model transparent और sustainable है, और तकनीकी रूप से यह ambitious व innovative होने के साथ-साथ practical और realistic भी है
• stability और व्यापक industry adoption तक पहुँचने में अभी समय लगेगा, लेकिन वे मानते हैं कि वहाँ तक पहुँचने का रास्ता और अवसर स्पष्ट हैं
• ZSF funding का लगभग एक-तिहाई हिस्सा individual donations से आता है, और वे सक्षम लोगों को दान करने की सलाह देते हैं

[GN⁺]

Hacker News की रायें

• “हमारी परोपकारी गतिविधियां आम तौर पर निजी रहती हैं, लेकिन मेरी पृष्ठभूमि को देखते हुए मुझे लगा कि Zig के लिए सार्वजनिक समर्थन इस प्रोजेक्ट की सच में मदद कर सकता है, इसलिए मैं अपवाद बना रहा हूं” — यह वाक्य अजीब तरह से मन को छू गया
  ठीक-ठीक कहना मुश्किल है, लेकिन इसमें जो बुनियादी गरिमा है, वह सराहना के लायक है

  • मुझे भी कुछ वैसा ही लगा, लेकिन शायद उलटी दिशा में
    क्या इसका मतलब है कि बाकी परोपकारी गतिविधियों में सार्वजनिक समर्थन मददगार नहीं होता? अगर ऐसा है, तो वे गतिविधियां किस तरह की हैं, यह जानने की उत्सुकता हुई। बेशक, अपने पैसे से की गई चैरिटी आखिरकार जैसे चाहें कर सकते हैं, लेकिन अभिव्यक्ति थोड़ी अजीब लगी
  • अगर पैसा दान करते हुए अपना नाम जोड़ना अपने-आप में मूल्य रखता है, तो यह पूरी तरह समझ में आता है
    इस मामले में वह सार्वजनिक समर्थन उनकी अपनी दान राशि से भी बड़ा अतिरिक्त योगदान खींच सकता है
  • जिस चीज़ पर भरोसा है उसे सपोर्ट कर रहे हैं, यह सीधे-सीधे बताना और यह समझाना कि परवाह क्यों है, मुझे पूरी तरह स्वाभाविक लगता है
  • सोच रहा हूं कि ऐसा सार्वजनिक समर्थन होने की वजह से है, या इसलिए कि परोपकारी गतिविधियां आम तौर पर निजी रहती हैं

• अगर Zig Foundation से जुड़े लोग देख रहे हों, तो जॉब बोर्ड बनाने की जोरदार सिफारिश करूंगा
  खास डोमेन के पाठक जहां हों, वहां यह लगभग मुफ्त कमाई का स्रोत होता है

  • मैं इसे आज़माऊंगा

• शायद यह मूर्खतापूर्ण सवाल हो, लेकिन वेब डेवलपर होने के कारण सिस्टम/लो-लेवल प्रोग्रामिंग से आम तौर पर सिर्फ जिज्ञासा के तौर पर ही सामना होता है
  लोग कहते हैं कि जहां संभव हो सब कुछ memory-safe languages में शिफ्ट करो, लेकिन Zig में ऐसी गारंटी दिखती नहीं। अगर Zig नई भाषा है, तो उसका मुख्य उपयोग नए प्रोजेक्ट ही होंगे; फिर memory-safe language से शुरुआत करनी चाहिए, ऐसा लगता है। अगर Zig की खूबी “C से ज्यादा आधुनिक और Rust से ज्यादा सरल” होना है, तो आकर्षण समझ आता है, लेकिन memory safety की कमी से क्या वह फायदा कमजोर नहीं पड़ जाता?

  • Memory safety उपयोगी अवधारणा है, लेकिन यह रामबाण भी नहीं और दो-टूक बाइनरी चीज़ भी नहीं
    अगर अंतिम लक्ष्य सिर्फ safety होता, तो JavaScript भी काफी होती। Safe Rust memory safety की गारंटी देता है, इसलिए सिस्टम प्रोग्रामिंग में यह बड़ा सुधार है, लेकिन हमेशा अंतिम जवाब नहीं है। एप्लिकेशन के हिसाब से trade-off होते हैं, और निजी तौर पर मुझे guaranteed safety से ज्यादा महत्वपूर्ण यह लगता है कि safety हासिल करना कितना आसान है। C और C++ की समस्या यह थी कि उन्हें safe बनाना बहुत कठिन था
  • जिन क्षेत्रों में Zig सच में चमकता है, वहां Rust में वही कोड लिखने पर बहुत unsafe लगने की संभावना है, यानी व्यवहार में memory-safety features बंद करने जैसा
    असल में Zig Rust से कम safe है या नहीं, यह अभी और देखना होगा। किसी भी तरफ, प्रोग्राम को safe बनाने के लिए बहुत सारे tests लिखने पड़ेंगे, और Rust जादू की तरह सारे bugs खत्म नहीं करता। Zig में भी debug mode में पर्याप्त testing करने पर अधिकतर memory safety bugs पकड़े जा सकते हैं। फिर भी अगर web browser जैसी चीज़ बनानी हो, तो शायद मैं Rust इस्तेमाल करूंगा
  • C/C++ में भी बहुत तेज और बहुत safe code लिखा जा सकता है
    गेम इंडस्ट्री को देखिए, या उस दौर के पूरे उद्योग को जब software को disk पर लिखकर वितरित करना पड़ता था। आज की समस्या यह है कि language complexity बढ़ गई है और software developers की औसत कुशलता घटी है। Google ने Go कुछ हद तक इसी समस्या को हल करने के लिए बनाया था, और Rust एक और भाषा है जिसने memory safety को design के केंद्र में रखा। Rust में ज्यादा safe प्रोग्राम लिखना आसान होने की एक और वजह यह है कि यह C++ से बहुत कम complex है। हालांकि यह भी धीरे-धीरे complex हो रहा है, लेकिन सौभाग्य से Rust community में memory safety की अवधारणा गहराई से जमी हुई है, इसलिए भाषा complex होने पर भी वह फायदा और developers की आदतें बनी रहेंगी
    अगर Zig भी safety को महत्व देता है, तो यह अच्छा विकल्प है। defer जैसे syntax से सरलता लाता है, और development के दौरान memory-safety issues पकड़ने के लिए कई execution targets और tools देता है। Compiler इसे enforce नहीं करता; development/non-ReleaseFast builds में runtime पर पकड़ने का तरीका है, लेकिन फिर भी यह C/C++ से बेहतर रूप है
  • Zig को पूरा का पूरा “memory-unsafe” कहकर ठप्पा लगाना मुझे ठीक नहीं लगता
    इसमें C में न होने वाले memory safety tools और checks काफी भरपूर हैं। Safety एक spectrum है। C, C++ से कम safe है; C++, Zig से कम safe है; Zig, Rust से कम safe है; Rust, Java से कम safe है; और Java, Python से कम safe है। Undefined behavior और memory corruption सभी में अभी भी संभव हैं; फर्क यह है कि वे कितनी आसानी से होते हैं
  • मुझे लगता है memory safety की कमी Zig की खूबियों को आंशिक रूप से कमजोर करती है
    हालांकि Zig अभी पूरी तरह तैयार भाषा नहीं है, इसलिए अभी निष्कर्ष निकालना कठिन है। Zig में भी अच्छे memory-safety features हैं, और यह JavaScript या Rust के स्तर का नहीं है, लेकिन C जैसा भी नहीं है। पहले जब मैंने देखा था, तो use-after-free बड़ी समस्या थी, और अगर यह हल नहीं हुआ तो मुझे Zig का भविष्य नहीं दिखता
    JavaScript सचमुच memory-safe language है, लेकिन उसका runtime और abstraction level सिस्टम प्रोग्रामिंग के लिए उपयुक्त नहीं है। सिस्टम प्रोग्रामिंग के लिए मेरी नजर में ऐसी चीज़ चाहिए जो मूल रूप से memory-safe हो लेकिन escape hatches भी हों, और abstraction इतना low-level हो कि compiler और CPU जिस virtual PDP-11 को सामान्यतः target करते आए हैं, उससे बस एक स्तर ऊपर हो। यह programmer को CPU execution model के हिसाब से सोचने दे लेकिन details में दफन न करे, और C के साथ interoperability भी बहुत अच्छी होनी चाहिए
    Rust ने पहली चीज़ अच्छी तरह की है। उसकी कमजोरी दूसरी है। Low-level features हैं, लेकिन language-feature complexity के ढेर के नीचे दबे हुए हैं। साथ ही यह कुछ पूरी तरह safe memory-management patterns की अनुमति नहीं देता, जिससे unsafe बहुत बार इस्तेमाल करना पड़ता है, या code को problem domain के बजाय solution domain के हिसाब से मोड़ना पड़ता है
    Zig की पहली चीज़ कमजोर है। अच्छे features हैं, लेकिन बड़े gaps भी हैं। दूसरी तरफ दूसरी चीज़ में यह काफी मजबूत है। मेरी उम्मीद है कि Zig default memory safety दे, लेकिन Rust से कहीं ज्यादा flexible तरीके से, और low abstraction व C interoperability के मामले में अपनी खूबियां बनाए रखे

• हाल में self-hosting पर जाने की खबर देखकर लगा कि यह खास तौर पर efficient project है जो दान की रकम बर्बाद नहीं करेगा

  • सोच रहा हूं कि आप Zig compiler के self-hosting पर जाने[1] की बात कर रहे हैं, या Zig website के self-hosting पर जाने[2] की। शायद बाद वाली बात होगी
    [1] https://kristoff.it/blog/zig-self-hosted-now-what/
    [2] https://ziglang.org/news/migrate-to-self-hosting/

• “सुनो, एक programming language है जो मुझे सच में बहुत पसंद है, उसके बारे में थोड़ी बात करनी है”
  “हां?…”
  “वह language मुझे सच में बहुत-बहुत पसंद है, तो मैं थोड़ा donation करना चाहता हूं…”
  “……फिर शुरू हो गए……”

  • या फिर ऐसा भी हो सकता है
    “अच्छा है! चलो अपनी Cirrus SF50 Vision में बैठकर Andrew Kelley को सीधे जाकर दे आते हैं”

• यह निश्चित रूप से अच्छी खबर है, लेकिन perspective के लिए कहें तो यह रकम compiler पर काम करने वाले skilled developer की करीब 0.75~1 साल की salary जितनी है
  मेरा अनुमान है कि Microsoft हर साल सिर्फ TypeScript पर ही इसका 10~20 गुना खर्च करता होगा, और C++/C# वगैरह पर तो इससे कहीं ज्यादा

  • ऐसे कमाने वाले developers भी हैं, और Microsoft या Mozilla जैसी जगहों पर इसकी संभावना ज्यादा है, लेकिन global market और छोटे compiler projects तक देखें तो सालाना 150,000 डॉलर से कम कमाने वाले skilled compiler developers भी काफी होंगे
    बेशक developer cost सिर्फ salary पर खत्म नहीं होती। फिर भी, बड़ी tech companies में ANSI standard compiler पर काम करने वाले compiler developer जैसी jobs में, ज्यादा स्वतंत्र काम की तुलना में वास्तविक काम काफी अप्रिय होता है, इसलिए मुझे लगा कि उसमें hazard pay जैसा हिस्सा काफी मिला हुआ है
  • ऐसे relatively नए, high-potential project में role, उन लोगों के लिए काफी आकर्षक मौका हो सकता है जिन्हें पहले से Zig पर भरोसा है
    सही funding हो तो यह catalyst बनता है, जिससे second job करने या सिर्फ रात/Weekend में काम करने की जरूरत नहीं रहती

• सच कहूं तो Zig से बहुत उम्मीदें हैं
  यह बिना फालतू चीजों के तेज-तर्रार है, और ऐसी language नहीं है जिसे किसी ivory-tower वाले ने बनाया हो जिसे वास्तविक usability की परवाह न हो। यह Haskell की तरह PhDs की team द्वारा design की गई भी नहीं है, लेकिन Rust या Haskell आदि के उपयोगी ideas से साफ तौर पर inspired लगती है। Zig में code लिखना काफी interesting होगा

  • मुझे भी Zig से वैसी ही उम्मीद है
    इसकी memory safety guarantees शायद Rust जितनी व्यापक न हों, लेकिन कभी Linux Kernel में Zig दिखे तो अच्छा होगा। पुराने kernel C programmers शायद Rust की तुलना में Zig को ज्यादा आसानी से अपना लें
  • मुझे पता है कि ऐसा view रखने पर Zig camp को पसंद नहीं आएगा, लेकिन vim या VS Code जैसी जगहों में zig fmt बंद करने की सुविधा आ जाए तो मैं फिर से Zig पर उम्मीद लगाऊंगा
    style preference को जबरन थोपना कड़वा लगता है। यह language को tool की तरह इस्तेमाल करने वाले developers का सम्मान न करने जैसा महसूस होता है। यह community participation और दूसरे perspectives के प्रति openness में किसी गहरी समस्या का संकेत भी हो सकता है, और Zig में सच में ऐसी समस्या दिखती है[0]
    जिन companies को code consistency चाहिए, उनके लिए linter चलाना काफी है, और weekend projects में मेरी अपनी style preference के अलावा मुझे किसी चीज की परवाह नहीं होती। सवाल यह है कि Zig वयस्कों के लिए language है या नहीं। अगर किसी खास तरीके से coding करने के लिए मजबूर ही होना है, तो Rust न इस्तेमाल करने की कोई वजह नहीं, जो साथ में memory safety भी मुफ्त में देता है
    [0] https://github.com/ziglang/zig/issues/16270