Zig के संस्थापक Andrew Kelley के साथ इंटरव्यू

 (youtube.com)
2 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Zig का लक्ष्य ऐसी सिस्टम भाषा होना है जो C की performance और control को बनाए रखते हुए footgun और debugging की कमजोरियों को कम करे, और CPU व memory के प्रति सीधी जागरूकता रखे
  • इसकी मुख्य भिन्नता toolchain है, जिसका लक्ष्य सिस्टम dependencies के बिना किसी भी OS पर चलकर किसी भी OS को target करते हुए सिर्फ zig build से build करना है
  • 1.0 में देरी backward compatibility का वादा जल्दबाज़ी में न करने का फैसला है, और 501(c)(3) non-profit संरचना की वजह से यह लंबे समय के सुधारों पर ध्यान दे सकता है
  • Zig Software Foundation ने 2024 में 670,000 dollars की आय दर्ज की और उसके पास sponsorship की विविध संरचना है; CI संचालन को प्राथमिकता देते हुए उसने GitHub से Codeberg पर स्थानांतरित किया
  • issues और pull requests पर no LLM, no AI नीति लागू है, क्योंकि उनका मानना है कि AI योगदान review time और mentorship को नुकसान पहुंचाता है और नकारात्मक मूल्य पैदा करता है

Zig की शुरुआत और language design

  • जन्म की पृष्ठभूमि

    • Andrew Kelley ने digital audio workstation बनाने के लिए JavaScript, Go, Rust, और C++ को क्रमशः आज़माया, लेकिन उनका मानना था कि इनमें से हर एक में उस user experience को बनाने की सीमाएँ थीं जो वे चाहते थे
    • उनका मानना था कि JavaScript browser के अंदर बहुत high-level है, इसलिए कंप्यूटर की क्षमताओं का पूरा उपयोग करना मुश्किल है
    • उनके अनुसार Go में C libraries के साथ interoperability अच्छी नहीं थी, और audio जैसे real-time कामों में जहाँ तय समय के भीतर processing पूरी होनी चाहिए, garbage collector glitch या skip पैदा कर सकता है, इसलिए वह उपयुक्त नहीं था
    • Rust में 1.0 से पहले के दौर में rules को satisfy करना कठिन था, छोटे बदलाव भी compiler errors की श्रृंखला बना देते थे, और font rendering को एक महीने तक ठीक करने के बाद भी आगे बढ़ना मुश्किल लगा
    • C++ शुरू में productive लगा, लेकिन छोटी typo या गलती भी memory corruption bug में बदल जाती थी, जिन्हें debug करने में हफ्तों लग जाते थे; और C++ compiler तथा C linker का उपयोग करने वाली “C-style C++” में भी footgun की समस्या बनी रही
    • Zig की शुरुआत इस दृष्टिकोण से हुई कि user experience से समझौता toolchain की सीमाओं के आधार पर नहीं, बल्कि कंप्यूटर मूल रूप से क्या कर सकता है इस आधार पर किया जाना चाहिए

  • C को replace कर सकने का कारण

    • उनका मानना है कि Zig C से बेहतर है, क्योंकि यह C की ताकत छोड़े बिना उसकी खामियों और कमजोरियों को बेहतर बनाता है
    • C को replace करने की दूसरी कोशिशों ने C की किसी न किसी चीज़ को छोड़ा, लेकिन Zig C जो कुछ कर सकता है वह सब कर सकता है, जबकि footgun कम करता है और debuggability बढ़ाता है
    • C में signed integer के लिए केवल optimized integer semantics हैं और unsigned integer के लिए केवल wraparound semantics, लेकिन Zig में signed/unsigned दोनों के लिए wraparound या no-overflow guarantee चुनी जा सकती है, इसलिए इसे C से भी अधिक “C-जैसा” कहा गया
    • उनका मानना है कि C को replace करने के लिए ऐसा code लिखना संभव होना चाहिए जिसे operating system kernels, embedded devices, video games, WebAssembly आदि हर जगह reuse किया जा सके; और यदि Zig C-स्तर की functionality और reliability देता है, तो लोग बेहतर performance और कम bugs वाले विकल्प को चुनेंगे

  • Rust से अंतर

    • Rust और Zig के बीच मुख्य अंतर type system है
    • Rust में यह नियम meta language में बताने पड़ते हैं कि function parameters clone को support करते हैं या नहीं, कौन-सा interface support करते हैं, और कौन-से types pass किए जा सकते हैं
    • Zig में ऐसे तंत्र के बिना concrete types pass किए जाते हैं, या फिर ऐसे generic types pass किए जाते हैं जो C++ templates की तरह काम करते हैं
    • यहाँ trade-off यह है कि Rust code में type system guarantees अधिक होते हैं, जबकि Zig code में पढ़े जाने वाले code की सादगी अधिक होती है
    • Rust, C++ जैसी RAII शैली की ओर बढ़ता है, जहाँ objects दूसरे objects को reference करते हैं और reference count 0 होने पर अपने-आप destruct हो जाते हैं
    • Zig में allocator कहीं अधिक explicit है; reference counting संभव है, लेकिन उसके लिए संबंधित code स्पष्ट रूप से लिखना पड़ता है
    • Zig में application के अनुरूप memory allocation methods का अक्सर उपयोग होता है; जैसे arena allocator से allocations को समूह में बाँधकर एक बार में छोड़ देना, या object-oriented approach के लिए general-purpose allocator का उपयोग करना, या किसी खास उपयोग के लिए मिश्रित तरीका बनाना
    • उनका मानना है कि CPU से आप क्या करवाना चाहते हैं, यह सोचकर उसी के अनुसार code लिखना Rust की तुलना में Zig में अधिक स्वाभाविक है

  • killer feature और toolchain

    • Zig का killer feature toolchain है
    • यह सिस्टम dependencies के बिना software tools का एक suite है, जो किसी भी operating system पर चल सकता है और किसी भी operating system के लिए code build कर सकता है
    • किसी project को hack करना कितना कठिन होगा, इसका अंदाज़ा README देखकर लगाया जा सकता है: क्या कई system packages install करने पड़ते हैं, क्या हर OS के लिए अलग प्रक्रिया है, क्या environment setup के लिए कई commands चलानी पड़ती हैं, या क्या Docker या खास hardware चाहिए
    • सबसे अच्छा मानक है एक पंक्ति, एक dependency, और हमेशा सबके लिए काम करने वाला setup, और Zig project के README में build step के लिए सिर्फ zig build पर्याप्त होना चाहिए

  • language rules और IO interfaces

    • unused variables को compile error मानने का नियम बड़े पैमाने के refactoring में bugs पकड़कर समय बचाता है, और variables को discard करने वाली टिप्पणी जोड़ने की लागत अधिक नहीं मानी जाती
    • ZLS टीम के editor support की वजह से setting चालू होने पर unused variables को अपने-आप discard किया जा सकता है, और फिर दोबारा इस्तेमाल होने पर वह discard हटाया जा सकता है
    • नया IO reader / IO writer interface image loading libraries या data format serialization code जैसे reusable code को एक बार लिखने के लिए बनाया गया abstraction है
    • लक्ष्य यह है कि जो data consume करता है वह reader को parameter के रूप में ले, जो output करता है वह writer को parameter के रूप में ले, उन्हें packages के रूप में अलग किया जाए, और कई applications में वही logic इस्तेमाल हो
    • abstraction layer के नीचे read और write होने पर compiler के लिए logic को समझकर optimize करना कठिन हो सकता है, जिससे performance का नुकसान हो सकता है
    • उनका मानना है कि interface के अंदर buffer शामिल करने वाला design वह संतुलन बिंदु है जहाँ compiler अच्छा code बना सकता है और reusability भी हासिल होती है

उपयोग के मामले, 1.0, और LLVM के बाद की दिशा

  • वास्तविक उपयोग के मामले

    • Zig को ऐसी भाषा के रूप में पेश किया जाता है जब आप कंप्यूटर पर पूरी तरह नियंत्रण चाहते हों, performance और memory usage को अधिकतम स्तर तक ले जाना चाहते हों, और एक प्रभावशाली user experience बनाना चाहते हों
    • Ghostty Mitchell Hashimoto द्वारा बनाया गया एक terminal emulator है, और code quality, community management, तथा fuzz testing के लिहाज़ से इसे एक अच्छा project माना जाता है
    • TigerBeetle एक financial transaction database है, जिसने PostgreSQL जैसे relational database के ऊपर OLTP चढ़ाने की रणनीति के बजाय एक special-purpose database बनाया, और कहा जाता है कि यह ऐसी रणनीति से “हज़ार गुना तेज़” है
    • TigerBeetle रनटाइम पर आगे इस्तेमाल होने वाली सारी memory पहले से allocate कर देता है और उसके बाद dynamic allocation नहीं करता, जिससे latency अनुमानित और लगातार बनी रहती है
    • Bun एक JavaScript engine है जो JavaScriptCore और कई C++ libraries का उपयोग करता है, और इसका glue code Zig में लिखा गया है
    • उनके अनुसार, Bun हाल ही में Anthropic को बेचा गया है, और इसके परिणामस्वरूप AI उपयोग के लिए Zig अपनाने वालों की संख्या बढ़ी है
    • Uber, Go code जिन C code पर निर्भर करता है उन्हें साथ में cross-compile करने के लिए Zigcc को C compiler के रूप में उपयोग करता है, और ARM64 target builds में इसका इस्तेमाल करता है

  • 1.0 में देरी क्यों हो रही है

    • Zig के 10 साल से अधिक समय हो चुके हैं, फिर भी 1.0 नहीं आया है, लेकिन 1.0 को वे मूलतः backward compatibility के वादे के रूप में देखते हैं, और हर project में इसका अर्थ अलग हो सकता है
    • तुलना में कहा गया कि Go ने 1.0 के बाद लंबे समय तक भाषा को लगभग नहीं छुआ, जबकि Rust ने 1.0 अपेक्षाकृत जल्दी जारी किया, लेकिन editions के ज़रिए backward compatibility बनाए रखते हुए भाषा में काफ़ी बदलाव कर सका
    • Zig Software Foundation कोई startup नहीं बल्कि 501(c)(3) nonprofit है, इसलिए उस पर investor pressure, sale, या exit plan का दबाव नहीं है, और उसके पास लंबी अवधि में सुधार करने का समय है
    • वे चाहते हैं कि 1.0 जल्दबाज़ी में बंद कर दिए गए खराब फ़ैसलों में फँसा हुआ न हो, बल्कि “समझौता-रहित लगाव की उपज” बने
    • “worse is better” के बारे में उनका मानना है कि यह अभिव्यक्ति भाषाई रूप से ही तर्कसंगत नहीं है, और Zig more with less का लक्ष्य रखता है
    • कम complexity वाले comptime feature से बड़ा लाभ लेने, और एक ही flag के साथ पूरी तरह अलग operating systems और architectures के लिए compile कर सकने वाली toolchain को दिशा के रूप में रखा गया है
    • उनका मानना है कि 1.0 आते ही adoption तेज़ी से बढ़ेगा, लेकिन लक्ष्य अगले 50 वर्षों के लिए भाषा बनाना है
    • उनका कहना है कि upcoming 0.16 release में इन विकल्पों के परिणाम दिखने शुरू हो सकते हैं

  • LLVM से दूर जाने की वजह

    • LLVM से दूर जाने का कारण यह है कि core product के लिए किसी core dependency पर निर्भरता से बचना चाहिए
    • उदाहरण के तौर पर 10-खिलाड़ियों वाला competitive arcade game Killer Queen दिया गया, जिसमें developer ने physics engine के लिए Unity का उपयोग किया था, और physics engine में छोटे बदलाव या bug fix से भी competitive play की feeling बदल जाती थी, इसलिए वे Unity के नए version पर update नहीं कर सके
    • इसे core product के लिए dependency रखना एक गलती माना गया, और Zig के लिए LLVM के संदर्भ में इसे सुधारने की प्रक्रिया के रूप में देखा गया
    • LLVM की तुलना “साइकिल के training wheels” से की गई, और कहा गया कि Zig को 10 साल से अधिक बनाते हुए compiler development की समझ बहुत बढ़ गई है, इसलिए अब training wheels हटाकर LLVM से प्रतिस्पर्धा की जा सकती है
    • अपने x86 backend में, बड़े पैमाने के million-line codebase पर भी बदलाव के बाद 50ms से कम समय में नया binary पाने वाली incremental compilation संभव है

  • नाम और सीखने का रास्ता

    • Zig नाम एक छोटे शब्द की तलाश में चुना गया था, जिसके लिए “Zig programming language” खोजने पर 0 results आते थे; इसे Python script से random words निकालते समय चुना गया
    • इसका mascot iguana “ziguana” कहलाता है
    • शुरुआती लोगों के लिए Ziglings की ज़ोरदार सिफारिश की जाती है
    • Ziglings ऐसे अभ्यासों की एक श्रृंखला है जिसमें लगभग काम करने वाले code में समस्याएँ डाली गई हैं, और टूटे हुए program को ठीक करते हुए नई language features सीखी जाती हैं
    • C से Zig में आना खास तौर पर आसान है; C में जो कुछ किया जा सकता है वह Zig में भी किया जा सकता है, और इसमें footgun कम हैं
    • C में segmentation fault होने पर आमतौर “segmentation fault” के अलावा कुछ नहीं दिखता और फिर debugger इस्तेमाल करने की क्षमता पर निर्भर रहना पड़ता है, जबकि Zig में हर code line की ओर इशारा करने वाला पूरा stack trace मिल सकता है
    • किसी को Zig अपनी पहली programming language के रूप में सीखनी चाहिए या नहीं, यह व्यक्ति पर निर्भर करता है, लेकिन जो लोग समझना चाहते हैं कि कंप्यूटर कैसे काम करता है, उनके लिए यह CPU और memory सीखने में मदद करने वाली एक अच्छी भाषा मानी जाती है

फ़ाउंडेशन संचालन, गवर्नेंस, प्लेटफ़ॉर्म चयन

  • वित्त और प्रायोजन संरचना

    • 2024 में Zig Software Foundation की कुल आय 670,000 डॉलर थी
    • आय के स्रोत व्यक्तिगत प्रायोजकों और कई कंपनियों के दान से विविध हैं, और संरचना ऐसी है कि कोई एकल इकाई विकास की दिशा थोप नहीं सकती
    • अगर कोई विशेष प्रायोजक कहे “यह करो”, तो उसे मना किया जा सकता है, और उस प्रायोजक के पैसा रोक देने पर भी संगठन के जीवित रहने की बात कही गई
    • प्रायोजक bug tracker में भागीदारी, pull request जमा करना, development channel में बातचीत जैसे उन्हीं तरीकों से प्रभाव डाल सकते हैं जैसे बाकी लोग; कोई अलग गुप्त high-priority channel नहीं है
    • Andrew Kelley का वार्षिक वेतन 154,000 डॉलर है, और कहा गया कि पहले बोर्ड ने इसे उस शहर में senior software engineer के median वेतन के आधार पर तय किया था जहाँ यह non-profit स्थापित की गई थी
    • फ़ाउंडेशन में 1 कर्मचारी और लगभग 5 full-time paid contractors हैं, और पिछले वर्ष की आय का 91% प्रोजेक्ट पर काम करने वाले contractors को दिया गया
    • बिना शर्त 100 million dollar के प्रस्ताव पर उनका जवाब था कि लिया तो जा सकता है, लेकिन उसे विकास पर खर्च नहीं करेंगे; बैंक में रख देंगे ताकि 100 साल तक फंडरेज़िंग न करनी पड़े
    • उन्होंने बताया कि वे अभी 5 लोगों की टीम संभाल रहे हैं, 10 से ऊपर जाना बोझिल हो सकता है, और 100 लोगों के संगठन के मैनेजर बनने का उनका इरादा नहीं है

  • 501(c)(3) और पारदर्शिता

    • 501(c)(3) को 501(c)(6) से अलग बताया गया
    • 501(c)(6) एक business league है, और Rust Foundation का उदाहरण इस रूप में दिया गया कि Amazon, Netflix, Microsoft, Meta जैसी कंपनियाँ Rust की सफलता में साझा हित रखती हैं और दान देती हैं
    • 501(c)(3) को सरकारी lobbying की अनुमति नहीं होती, और यह कारोबारी हितों के लिए नहीं बल्कि सिर्फ mission statement के लिए मौजूद होता है
    • आय और खर्च का विस्तृत खुलासा करने वाली ब्लॉग पोस्ट कोई अनिवार्यता नहीं बल्कि स्वैच्छिक पारदर्शिता है, और उनका मानना है कि अच्छे metrics होने के कारण इससे भरोसे और फंडरेज़िंग, दोनों में मदद मिलती है

  • GitHub और सोशल मीडिया छोड़ने के कारण

    • Reddit और Twitter छोड़ने का कारण यह था कि उन साइटों पर पोस्ट करना धीरे-धीरे Slashdot या Digg पर पोस्ट करने जितना कम प्रासंगिक होता जा रहा था, और वे software engineer के रूप में marketing पर बिताया समय न्यूनतम रखना चाहते थे
    • उनका मानना है कि algorithm क्या दिखेगा इसे नियंत्रित करने वाले या trolls से उलझाने वाले सोशल मीडिया की तुलना में, in-person events और meetup पर ज़्यादा ध्यान देना community growth के लिए बेहतर निवेश है
    • 2025 के अंत में Zig का main repository GitHub से Codeberg पर ले जाने का कारण यह था कि GitHub अब continuous integration results ठीक से नहीं दे रहा था, यानी “वह बस काम ही नहीं कर रहा था”
    • Codeberg पर जाने के बाद continuous integration server फिर से काम करने लगा
    • GitHub Sponsors छोड़ना कठिन फैसला था क्योंकि इससे आय का एक स्रोत खो सकता था, लेकिन software लिखने के लिए CI का काम करना सर्वोच्च प्राथमिकता माना गया
    • GitHub छोड़ने के बाद वित्तीय स्थिति को उन्होंने “पूरी तरह ठीक” बताया
    • Zig, MIT license वाला software है, जिसे software जगत के लिए बिना शर्त दान माना गया, और sponsorship को भी बिना शर्त दान के रूप में देखा गया
    • Codeberg चुनने का कारण यह था कि वह मूल रूप से GitHub जैसा ही है, इसलिए migration आसान था, और वह एक जर्मन non-profit है
    • उनका मानना है कि code forge किसी प्रोजेक्ट का marketing माध्यम नहीं है; लोग भाषा को GitHub या Codeberg से नहीं बल्कि announcements, meetup, YouTube videos, Zigday meetup groups जैसी जगहों से खोजते हैं

  • BDFL और दीर्घकालिक गवर्नेंस

    • software projects को अक्सर hierarchical control और democratic process में से एक चुनना पड़ता है, और कई projects सादगी के कारण BDFL मॉडल अपनाते हैं
    • अगर एक व्यक्ति नियंत्रण में है, तो उस पर यह ज़िम्मेदारी होती है कि वह सब कुछ समझे और प्रोजेक्ट के लिए सुसंगत विज़न रखे
    • committee में अलग-अलग वैध use cases और visions टकरा सकते हैं, और जब कोई एकल design दोनों use cases को एक साथ संतुष्ट नहीं कर सकता, तब समझौता एक बदतर product तक ले जा सकता है
    • Andrew Kelley के चले जाने पर भी, software engineering के नज़रिए से उनके सहयोगियों को प्रोजेक्ट चलाते रहने के लिए बहुत सक्षम माना गया
    • संगठन और फ़ाउंडेशन के राजनीतिक दृष्टिकोण से अभी भी काम बाकी है, और इस सोच के आधार पर कि जहाँ पैसा बहता है वहाँ भ्रष्टाचार आता है, फिलहाल पैसे के प्रभाव का प्रतिरोध करने वाला मज़बूत hierarchical leadership ज़रूरी माना गया
    • एक मज़बूत नेता द्वारा सब कुछ नियंत्रित करने का तरीका टिकाऊ नहीं है, इसलिए दीर्घकालिक स्थिरता के लिए democracy ज़रूरी है, लेकिन चुनौती यह है कि उसे इस तरह डिज़ाइन किया जाए कि समय के साथ पैसे के प्रभाव से वह भ्रष्ट न हो

  • सफलता के मानदंड

    • Zig की सफलता एक नज़रिए से पहले ही हासिल हो चुकी है
    • उसके पास विविध आय स्रोत हैं, इसलिए वह किसी एक इकाई से वित्तीय रूप से स्वतंत्र है, उसके उपयोगकर्ता संतुष्ट हैं और लगातार इस्तेमाल कर रहे हैं, और वह हर साल लगभग दो बार release करता है तथा लगातार सुधार कर रहा है
    • दूसरे नज़रिए से वह अधिक adoption चाहता है, और सफलता का एक मापदंड Go और Rust के स्तर का adoption है
    • commercial adoption उपयोगी है क्योंकि उससे corporate donations मिल सकती हैं, लेकिन corporate donations में भी विविधता बनाए रखने के लिए सावधानी ज़रूरी है
    • उनका मानना है कि अगर आप ऐसी चीज़ बनाते हैं जो आम तौर पर उपयोगी हो, तो वह कंपनियों के लिए भी उपयोगी हो जाती है, और लोग Zig को AI में इस्तेमाल कर रहे हैं, इससे भी यह बात दिखती है

AI नीतियां, डेवलपमेंट टूल्स, और प्रोग्रामिंग का भविष्य

  • no LLM, no AI योगदान नीति

    • Zig में issues और pull requests के लिए सख्त no LLM, no AI policy है
    • उनका मानना है कि AI योगदान “हमेशा की तरह कचरा” है, और सिर्फ बेकार ही नहीं बल्कि review time छीनकर नकारात्मक value भी बनाता है
    • इस समय 200 से ज़्यादा open pull requests हैं, और छोटी development team तथा बहुत से contributors के बीच review time ही bottleneck है
    • उनका मानना है कि AI से बने योगदानों में कुछ rounds के review के बाद यह पैटर्न दिखता है कि contributor खुद सामग्री नहीं समझता, review feedback को chat में paste करता है, फिर मिले जवाब को अपने शब्दों की तरह पेश कर देता है
    • code review और contributions लेने का मूल कारण mentorship है, और लक्ष्य यह है कि contributor आगे चलकर core team member बने या अधिक मूल्यवान contributor के रूप में विकसित हो
    • “contributor poker” सीमित समय को किस पर निवेश किया जाए ताकि वह बेहतर programmer और contributor बन सके, यह तय करने की प्रक्रिया है
    • उनका मानना है कि AI का उपयोग करने वाला व्यक्ति हमेशा कम निवेश-मूल्य वाले one-off contributor की श्रेणी में आता है, जो न सीखता है और न core team का हिस्सा बनने की संभावना रखता है
    • Zig project एक educational project भी है, और students को guidance तथा education देना उसके mission का हिस्सा है
    • अगर “सिर्फ अच्छे AI PR” की अनुमति दी जाए, तो उसके लिए निर्णय लेने वाला चाहिए, लेकिन पूर्ण प्रतिबंध लागू करना आसान policy है
    • वे मानते हैं कि AI-generated होने का पता लगाना हमेशा आसान नहीं होता और कुछ चीज़ें शायद अंदर आ भी गई हों, लेकिन बहुत सारे pull requests review करते समय, feedback मिलने पर जो व्यवहार दिखता है उससे कई बार साफ़ हो जाता है कि यह इंसानी प्रतिक्रिया नहीं है

  • MIT लाइसेंस और AI training

    • Zig codebase MIT license के तहत है, और जो लोग software licenses से परिचित नहीं हैं उनके लिए यह लगभग public domain जैसा है
    • इसे लगभग किसी भी उद्देश्य के लिए इस्तेमाल किया जा सकता है, code copy करते समय license को पुन: प्रस्तुत करना होता है, कोई warranty नहीं है, और किसी समस्या के लिए Zig पक्ष को ज़िम्मेदार नहीं ठहराया जा सकता
    • बड़ी कंपनियां Zig code को AI training में इस्तेमाल कर सकती हैं, लेकिन Zig में AI का योगदान प्रतिबंधित है — वे इसे एक विडंबना मानते हैं
    • उनका यह स्पष्ट विश्वास है कि Zig दुनिया के लिए बिना शर्त दिया गया एक उपहार है, इसलिए AI training में इसका उपयोग होना भी उन्हें स्वीकार्य है
    • उन्होंने खुद बहुत ज़्यादा कोशिश नहीं की कि LLM को Python या JavaScript की तुलना में Zig code में अधिक कठिनाई होती है या नहीं, लेकिन Mitchell Hashimoto के अनुसार Ghostty में AI coding का व्यापक उपयोग होता है
    • Rocker नाम के एक screen name वाले व्यक्ति ने Zig में AI को बेहतर काम कराने वाला टूल बनाया और सफलता देखी

  • vibe coding और प्रोग्रामिंग का भविष्य

    • किसी project को लंबे समय तक करते हुए skills सीखने और problem solving के बारे में पढ़ना कल्पना को उकसाता है, यह सोचने पर मजबूर करता है कि हम खुद क्या बना सकते हैं, और कुछ सिखाने के साथ भावनात्मक जुड़ाव भी बनाता है
    • उनका मानना है कि vibe coding blogs — जैसे “Claude के इस version या OpenAI के उस version को आज़माया और वह हैरान करने वाली तरह से अच्छा निकला” — प्रेरणा नहीं देते
    • वे ज़ोर देकर कहते हैं कि software quality का मानक “हैरानी की बात है कि इसमें bugs नहीं हैं” नहीं, बल्कि बिना समझौते की पूर्णता होना चाहिए
    • Richard Feldman के साथ एक private call में उन्होंने vibe coding आज़माई, और उनका मानना है कि यह technology मूल रूप से दिलचस्प है
    • लेकिन लगभग चार कंपनियों द्वारा इसे केंद्रीय रूप से नियंत्रित किया जाना, और models तथा व्यवहार पर उनका पूर्ण नियंत्रण होना, उन्हें गहराई से अस्वीकार्य लगता है
    • उनका कहना है कि वे अपने कंप्यूटर और अपनी बिजली का उपयोग करके code लिखने के तरीके से हटकर, network के पार किसी और के कंप्यूटर पर closed-source programming को monthly subscription के साथ इस्तेमाल करने वाले मॉडल में नहीं जाना चाहते
    • कुछ लोग हर महीने 300 डॉलर दे रहे हैं, और वे कहते हैं कि ऐसा प्रस्ताव उन्हें पागलपन जैसा लगता है
    • उनका मानना है कि 10 या 20 साल बाद भी इंसान code लिखते रहेंगे, और coding मज़ेदार है, इसलिए कम से कम hobby के रूप में तो हमेशा बनी रहेगी
    • उनका मानना है कि फोन और कंप्यूटर पर सबसे अच्छे apps वे हैं जिन्हें लोगों ने अपने खाली समय में hobby के रूप में बनाया है, और free/open-source software तथा अपनी device के मालिक बने रहने की इच्छा खत्म नहीं होगी

  • editing environment और refactoring tools

    • Zig का syntax बदलने पर भी code संपादित करते रहने के लिए resilient working environment की ज़रूरत है
    • tree-sitter और language server जैसे advanced tools stable syntax tree या stable language को आधार मानते हैं, इसलिए भाषा टूटे तो वे भी साथ में टूट सकते हैं
    • व्यक्तिगत रूप से Zig लिखते समय वे उन्नत environment की बजाय terminal और Vim का उपयोग करते हैं, और Vim बदलावों को बहुत अच्छी तरह झेल लेता है
    • ZLS का अर्थ Zig language server है, यह Zig के लिए Language Server Protocol implementation है, और Zig Software Foundation द्वारा संचालित नहीं बल्कि एक third-party project है
    • Zig website JetBrains products की सिफारिश करती है, लेकिन Andrew Kelley ने JetBrains products कभी इस्तेमाल नहीं किए क्योंकि वे closed source हैं
    • वे अतीत में JetBrains या Eclipse द्वारा दिए जाने वाले high-level refactoring tools, जैसे function extract करना, function parameters को reorder करना, और global rename जैसी सुविधाओं को अच्छा मानते थे
    • लंबे समय में वे type information और अन्य संकेतों के आधार पर बड़े बदलाव कर सकने वाले query language जैसे refactoring tool चाहते हैं
    • variable rename जैसे स्पष्ट scope वाले काम अगर कोई विश्वसनीय tool संभाले, तो वे नतीजे पर 100% भरोसा कर सकते हैं — इतना कि commit बनाकर उसकी review करने की भी ज़रूरत न पड़े
    • वही काम अगर AI tool से कराया जाए, तो अभी भी code review करना पड़ता है, इसलिए वह विश्वसनीय refactoring tool की तुलना में ज़्यादा समय लेता है और बदतर विकल्प बन जाता है

व्यक्तिगत प्रेरणा और ओपन सोर्स पर नज़रिया

  • Zig को जारी रखने की प्रेरणा और कठिनाइयाँ

    • Zig पर काम करने की प्रेरणा कंप्यूटर से प्रेम और यह चाहत है कि कंप्यूटर इंसानों की सेवा करें
    • Zig को एक बेहतरीन programming language और toolchain के रूप में देखा जाता है, जो ऐसे नतीजे तक ले जा सकता है, और इसे आशावादी उपहार के रूप में व्यक्त किया गया
    • users को संतुष्ट करना और एक मज़बूत user experience बनाना बहुत संतोष देता है, और अच्छे software बनाने की भावना की तुलना एक musician के मंच पर प्रदर्शन करने से मिलने वाली अनुभूति से की गई
    • non-profit organization चलाने के लिए ज़रूरी tax और paperwork को सबसे कठिन हिस्सा बताया गया
    • कानूनी रूप से बिना समस्या के संचालन करने और बड़े donation लेने के लिए यह अनिवार्य है, लेकिन फिलहाल यह काम Andrew Kelley ही संभाल रहे हैं
    • कुछ दिनों में वे accounting का काम करते हैं, और कुछ दिनों में programming; programming वाले दिनों को वे अच्छा दिन मानते हैं
    • Zig 0.15 में IO reader / IO writer interface का बदलाव सही संतुलन खोजने, API बनाने, testing करने और दूसरी programming languages से तुलना करके नया समाधान निकालने का नतीजा था, लेकिन उसके बाद 6 महीनों तक standard library और ecosystem projects को ठीक करना पड़ा

  • burnout और सलाह

    • उनका मानना है कि burnout तब होता है जब बहुत मेहनत की जाए लेकिन उस मेहनत का पर्याप्त प्रतिफल न दिखे
    • Andrew Kelley बहुत मेहनत करते हैं, लेकिन खुश users, Zig releases, release notes और improvements जैसे प्रतिफल देखते हैं, इसलिए वे आम तौर पर burnout से बचे रहते हैं
    • IO बदलाव जैसे काम, जिनका प्रतिफल कई महीनों बाद मिलता है, burnout जैसा महसूस हो सकते हैं, लेकिन आखिरकार प्रतिफल मिलने पर स्थिति बेहतर हो जाती है
    • जो लोग burnout झेल रहे हों, उन्हें वे पहले exercise, पर्याप्त नींद और healthy diet पर ध्यान देने की सलाह देते हैं
    • अगर आपको अपना काम पसंद नहीं है या लगता है कि आपकी company दुनिया के लिए कोई मूल्यवान काम नहीं कर रही, लेकिन फिर भी आपको कड़ी मेहनत करनी पड़ रही है, तो burnout की स्थिति बनती है
    • ऐसे में दूसरी नौकरी ढूँढ़ना या startup की तरह अपना काम बनाना एक विकल्प हो सकता है; और अगर आप किसी “आत्माहीन corporation” में काम कर रहे हैं, तो शाम 5 बजे घर जाएँ, बाकी काम करें और ज़रूरत से ज़्यादा मेहनत न करें

  • जिन projects का सम्मान करते हैं और browser diversity

    • जिन projects का वे सबसे पहले सम्मान करते हैं, उनमें Linux शामिल है
    • उनका मानना है कि अगर दुनिया में सिर्फ proprietary operating systems होते तो स्थिति बहुत खराब होती; Linux ने न सिर्फ free·open source developers बल्कि दुनिया भर के देशों और companies को भी मुफ्त में अपना business बनाने का मौका दिया, इसलिए यह अर्थव्यवस्था के लिए भी अच्छा रहा
    • दूसरा है Blender, जिसे वे एक ऐसा open source project और non-profit organization मानते हैं जो professional स्तर पर इस्तेमाल होता है और बहुत पैसा व development manpower रखने वाली companies से मुकाबला करते हुए जीत भी रहा है
    • तीसरा है VLC; उन्होंने याद किया कि जब वे पहले FFmpeg में योगदान दे रहे थे, तब VLC organization ने VLC या उसकी dependent libraries में योगदान देने वाले लोगों की VideoLAN Dev Days यात्रा लागत उठाई थी
    • Firefox इस्तेमाल करने की वजह browser diversity को लेकर चिंता है
    • Microsoft द्वारा Internet Explorer बंद करने के बाद मुख्य browsers सिर्फ Chromium, Safari और Firefox बचे हैं, और उनका मानना है कि Chromium का बाज़ार के ज़्यादातर हिस्से पर कब्ज़ा वेब के लिए समस्या है
    • हाल के समय में वे Mozilla से संतुष्ट नहीं हैं; उनका कहना है कि non-profit organization होने के बावजूद उसमें काफी corruption है और कई बातें ऐसी लगती हैं जैसे वह users के हितों के साथ aligned नहीं है
    • Chromium Google का है, Safari Apple का है, Firefox गिरावट में दिखता है, इसलिए विकल्प कम हैं; और नए browser projects के mature होने से पहले क्या करना चाहिए, यह उन्हें स्पष्ट नहीं लगता

  • अगर 2015 में वापस जाएँ तो क्या फिर भी Zig शुरू करेंगे

    • उनका जवाब है कि 2015 में वापस जाने पर भी वे ज़रूर Zig शुरू करेंगे
    • OkCupid छोड़कर Zig को full-time शुरू करने का दिन, बाद की जीवन-यात्रा को देखते हुए, उनके जीवन का सबसे बेहतरीन दिन था
    • Zig ने उन्हें गहरी संतुष्टि, स्वतंत्रता, self-worth और समाज में योगदान देने का एहसास दिया
    • उनका मानना है कि वे मूल रूप से ऐसे व्यक्ति हैं जिन्हें नौकरी पर रखना मुश्किल है; खुश रहने के लिए उन्हें खुद अपना boss बनना था, और उस स्थिति में आने के बाद ही उन्हें खुशी मिली

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Lobste.rs की राय
  • Zig Software Foundation के बाहर के लोग भी उम्मीद है कि Andrew और core team जब इस प्रोजेक्ट को आगे बढ़ाते हैं, तब उनके जुनून और दर्शन को समझें
    JetBrains ने इंटरव्यू को थोड़ा ज़्यादा provocative बनाकर viral करने की कोशिश की हो, इसके लिए उन्हें दोष नहीं दिया जा सकता, लेकिन नतीजे में सबसे अच्छे सवाल Zig बनाम Rust नहीं थे, बल्कि non-profit, sustainability, और प्यार से बनाए जा रहे Zig के बारे में थे
    लगता है Andrew ने प्रोजेक्ट के पीछे चुपचाप जलते उस मानवीय पहलू को दुनिया के सामने अच्छी तरह दिखाया
    • सच कहूँ तो JetBrains ने इसे किसी खास sensational दिशा में धकेला हो, ऐसा भी नहीं लगा
      वीडियो उन लोगों को, जिन्होंने Zig काफी इस्तेमाल किया है, उससे ज़्यादा उन लोगों को target करता हुआ लगा जो Zig के बारे में जानना चाहते हैं और जो project operations में दिलचस्पी रखते हैं, और उसने बस उन विषयों को उठाया जिनसे वह audience परिचित हो सकती थी
      interviewer ने भी आग भड़काने के बजाय Andrew की बातों को अपने आप सामने आने दिया, और इस तरह के इंटरव्यू के हिसाब से यह काफ़ी thoughtful था
      हाँ, subtitles में जिन शब्दों को जोड़ने का फैसला किया गया था, उन्हें देखकर हँसी ज़रूर आई; Zig में दिलचस्पी रखने वाला लेकिन Linux या abstraction की परिभाषा न जानने वाला कोई कितना होगा, यह पता नहीं
      कुल मिलाकर, Zig को दिखाने के तरीके के लिहाज़ से भी और JetBrains marketing team के बारे में बनी छाप के लिहाज़ से भी यह बहुत positive था
  • बीच में Andrew ने Zig और AI के इस्तेमाल में मदद करने के लिए मेरे बनाए tool का ज़िक्र किया था; जो लोग इसे आज़माना चाहते हैं, उनके लिए बता दूँ कि वह tool zigdoc है: github.com/rockorager/zigdoc
    मूल रूप से यह एक command-line tool है जो Zig standard library और build graph में मिली dependencies के documentation को दिखाता है
  • वीडियो के आख़िरी कुछ सेकंड में Andrew का यह कहना कि वह खुश हैं, मुझे सच में बहुत अच्छा लगा
  • “समझौते के बिना प्यार का श्रम” जैसा वर्णन बिल्कुल सही बैठता है
    1.0 को जल्दी न लाने वाला framing आकर्षक है, लेकिन Zig इस मायने में भाग्यशाली भी है कि उसके पास ऐसे users हैं जो ecosystem में बदलाव से आने वाले उतार-चढ़ाव को सह लेते हैं
  • embedded क्षेत्र में कई सालों तक C ही मुख्य tool रहा है
    C++ नहीं, बस C
    मैं लगातार सोच रहा था कि अगला embedded project Zig में करूँ या Rust में, लेकिन अब सच में लग रहा है कि “समय आ गया है”
    यह इंटरव्यू मेरे लिए निर्णायक मोड़ बन सकता है, और इसमें एक कुल मिलाकर महसूस होने वाला स्वर है जिससे गहरी सहमति बनती है
  • Zig के LLVM से अलग होने की वजह पर दिया गया जवाब सच में बहुत अच्छा था
    उसने अच्छी तरह छुआ कि Zig की core functionality से जुड़े किन हिस्सों पर team को ज़्यादा control होना चाहिए