बिल्कुल, मैं भी production में .asyncio का बहुत ज़्यादा इस्तेमाल करता हूँ, लेकिन मौजूदा उपयोग अनुभव से मैं इतना संतुष्ट नहीं हूँ कि यह कह सकूँ, 'मैं इसका अच्छी तरह इस्तेमाल कर रहा हूँ।'
मौजूदा asyncio को GIL को आधार मानकर डिज़ाइन किया गया है; एक तरह से देखें तो यह GIL से बचने की रणनीति है, इसलिए GIL सीधे asyncio के साथ इंटरैक्ट नहीं करता।
लेकिन asyncio पर आधारित पूरे concurrency programming के नज़रिए से देखें, तो यह कहना कि GIL अप्रासंगिक है, मुझे कुछ वैसा लगता है जैसे कहना, 'Python है, तो न होना स्वाभाविक है.'
मैं इस बात से सहमत हूँ कि मौजूदा GIL की दिशा से, "दूसरे विकल्पों" की तुलना में भी, किसी खास कमी न रहने जैसी स्थिति की उम्मीद करना मुश्किल है।
लेकिन Python के अलावा कोई दूसरा विकल्प अपनाना चाहिए, यह बात इस तर्क की ओर नहीं जानी चाहिए कि कोई समस्या ही नहीं है; बल्कि यह इस तर्क की ओर जानी चाहिए कि समस्या है, ऐसा मुझे लगता है।
इस बार मैंने सिर्फ अपनी व्यक्तिगत रुचि से, अपने मूल डेवलपमेंट क्षेत्र से बिल्कुल अलग वेब डेवलपमेंट को एक बार आज़माया। मैंने next.js v15 app router से एक बोर्ड बनाया था.. लेकिन हर बार ऐसे लेख देखता हूँ तो लगता है कि वेब की तरफ कुछ नया करने की इच्छा ही कम हो जाती है। यह ecosystem इतना अस्थिर क्यों है? फिर अगर कुछ नया आ गया तो क्या सब लोग उधर दौड़ पड़ेंगे, थोड़ा इस्तेमाल करेंगे, फिर उसे कोसते हुए कुछ और ढूँढ़ने लगेंगे? वेब डेवलपमेंट सच में काफ़ी मुश्किल लगता है।
ताकत और पैसा ही किसी प्रोजेक्ट को बनाए रखने की प्रेरक शक्ति होते हैं।
जब भी कोई वेबपेज Chromium के बिना ठीक से काम नहीं करता दिखता है, तो आह निकलना स्वाभाविक है।
सच कहूँ तो.... Google के अलावा शायद ही कोई ऐसी कंपनी होगी जो Chrome को कम-से-कम इस स्तर तक बनाए रख सके। और सेमीकंडक्टर जितना नहीं तो भी, web browser बाज़ार पर पकड़ भी ऐसा हिस्सा है जिसे अमेरिका आसानी से छोड़ना नहीं चाहेगा.... आगे भी मुझे लगता है कि कुछ हद तक monopoly को बर्दाश्त किया जाएगा।
लेख में यह बात साफ़ तौर पर नहीं कही गई है, लेकिन क्या इसका मतलब यह भी हो सकता है कि AI से लिखा गया code, इंसान द्वारा सीधे लिखे गए code की तुलना में कम परिचित होने के कारण debt बन जाता है?
अरे, मैं भी paid user था haha
App Store हिस्ट्री देखी तो पता चला कि 1.51 से यह free हो गया है.
मेरे लिए यह ज़रूरी tool है, क्योंकि मेरे MacBook की monitor settings इस्तेमाल की जगह के हिसाब से अलग-अलग होती हैं.
मुझे लगता है GIL का ज़िक्र थोड़ा अचानक-सा आ गया है.. GIL हट भी जाए, तब भी
अगर I/O bound और CPU bound दोनों में multi-threading इस्तेमाल करनी हो,
तो Python के बजाय कोई दूसरा विकल्प अपनाना बेहतर नहीं होगा..
वैसे asyncio को Python में गहराई से काम करने वाले लोगों के बीच काफ़ी नापसंद किया जाता है, ऐसा लगता है।
मुझे अक्सर यह राय सुनने को मिली है कि gevent को mainsteam बन जाना चाहिए था
asyncio काफ़ी इस्तेमाल होता है.. और काम का है.. task cancellation के edge-triggered (level-triggered नहीं) होने की एक सीमा है, लेकिन सच कहें तो ऐसा कोड लिखना, जो task cancellation के प्रति aware हो और gracefully handle करे, बहुत आम बात नहीं है। उससे भी बड़ी समस्या यह है कि event loop task के लिए weak reference रखता है, इसलिए वह GC की वजह से गायब हो सकता है.. लेकिन structured concurrency से यह हल हो जाता है.
ज़्यादातर प्रमुख i/o कामों के लिए asyncio सपोर्ट करने वाली लाइब्रेरी ढूँढने में कोई समस्या नहीं होती..
GIL? इसका इससे बहुत बड़ा संबंध नहीं है.. asyncio को CPU intensive कामों में parallelism के लिए इस्तेमाल करने का नज़रिया ही थोड़ा अजीब है.. GIL बेहतर होगा तो CPU intensive multithreading में वह उपयोगी होगा.. async का मकसद i/o bottleneck वाले हिस्सों को जितना हो सके उतनी efficiently चलाना है...
खैर, निष्कर्ष.. डिज़ाइन के स्तर पर कुछ समस्याएँ ज़रूर हैं, लेकिन लक्ष्य हासिल करने के लिए इसे इस्तेमाल करने में कोई खास दिक्कत नहीं हुई, और production में इसका अच्छे से उपयोग हो रहा है.
https://github.com/kelseyhightower/nocode
ऊपरी तौर पर code lines (LOC) की संख्या भी महत्वपूर्ण है। उत्पादकता के लिहाज़ से एक पेज पढ़कर समझना और 3 लाइनें पढ़कर समझना अलग बात है।
बिल्कुल, मैं भी production में
.asyncioका बहुत ज़्यादा इस्तेमाल करता हूँ, लेकिन मौजूदा उपयोग अनुभव से मैं इतना संतुष्ट नहीं हूँ कि यह कह सकूँ, 'मैं इसका अच्छी तरह इस्तेमाल कर रहा हूँ।'मौजूदा
asyncioको GIL को आधार मानकर डिज़ाइन किया गया है; एक तरह से देखें तो यह GIL से बचने की रणनीति है, इसलिए GIL सीधेasyncioके साथ इंटरैक्ट नहीं करता।लेकिन
asyncioपर आधारित पूरे concurrency programming के नज़रिए से देखें, तो यह कहना कि GIL अप्रासंगिक है, मुझे कुछ वैसा लगता है जैसे कहना, 'Python है, तो न होना स्वाभाविक है.'मैं इस बात से सहमत हूँ कि मौजूदा GIL की दिशा से, "दूसरे विकल्पों" की तुलना में भी, किसी खास कमी न रहने जैसी स्थिति की उम्मीद करना मुश्किल है।
लेकिन Python के अलावा कोई दूसरा विकल्प अपनाना चाहिए, यह बात इस तर्क की ओर नहीं जानी चाहिए कि कोई समस्या ही नहीं है; बल्कि यह इस तर्क की ओर जानी चाहिए कि समस्या है, ऐसा मुझे लगता है।
इस बार मैंने सिर्फ अपनी व्यक्तिगत रुचि से, अपने मूल डेवलपमेंट क्षेत्र से बिल्कुल अलग वेब डेवलपमेंट को एक बार आज़माया। मैंने next.js v15 app router से एक बोर्ड बनाया था.. लेकिन हर बार ऐसे लेख देखता हूँ तो लगता है कि वेब की तरफ कुछ नया करने की इच्छा ही कम हो जाती है। यह ecosystem इतना अस्थिर क्यों है? फिर अगर कुछ नया आ गया तो क्या सब लोग उधर दौड़ पड़ेंगे, थोड़ा इस्तेमाल करेंगे, फिर उसे कोसते हुए कुछ और ढूँढ़ने लगेंगे? वेब डेवलपमेंट सच में काफ़ी मुश्किल लगता है।
ताकत और पैसा ही किसी प्रोजेक्ट को बनाए रखने की प्रेरक शक्ति होते हैं।
जब भी कोई वेबपेज Chromium के बिना ठीक से काम नहीं करता दिखता है, तो आह निकलना स्वाभाविक है।
सच कहूँ तो.... Google के अलावा शायद ही कोई ऐसी कंपनी होगी जो Chrome को कम-से-कम इस स्तर तक बनाए रख सके। और सेमीकंडक्टर जितना नहीं तो भी, web browser बाज़ार पर पकड़ भी ऐसा हिस्सा है जिसे अमेरिका आसानी से छोड़ना नहीं चाहेगा.... आगे भी मुझे लगता है कि कुछ हद तक monopoly को बर्दाश्त किया जाएगा।
जांचने में देर हो गई।
इतने मन से दिए गए जवाब के लिए धन्यवाद!
असुविधा महसूस हो तब भी, इस्तेमाल करते-करते क्या हम जल्दी अभ्यस्त नहीं हो जाते?
इंसान अनुकूलन करने वाला जीव है।
लेख में यह बात साफ़ तौर पर नहीं कही गई है, लेकिन क्या इसका मतलब यह भी हो सकता है कि AI से लिखा गया code, इंसान द्वारा सीधे लिखे गए code की तुलना में कम परिचित होने के कारण debt बन जाता है?
अरे, मैं भी paid user था haha
App Store हिस्ट्री देखी तो पता चला कि 1.51 से यह free हो गया है.
मेरे लिए यह ज़रूरी tool है, क्योंकि मेरे MacBook की monitor settings इस्तेमाल की जगह के हिसाब से अलग-अलग होती हैं.
यह कोई thesis लिखना तो है नहीं, लेकिन...
मुझे लगता है GIL का ज़िक्र थोड़ा अचानक-सा आ गया है.. GIL हट भी जाए, तब भी
अगर I/O bound और CPU bound दोनों में multi-threading इस्तेमाल करनी हो,
तो Python के बजाय कोई दूसरा विकल्प अपनाना बेहतर नहीं होगा..
वैसे asyncio को Python में गहराई से काम करने वाले लोगों के बीच काफ़ी नापसंद किया जाता है, ऐसा लगता है।
मुझे अक्सर यह राय सुनने को मिली है कि gevent को mainsteam बन जाना चाहिए था
अच्छे ऐप का परिचय कराने के लिए धन्यवाद।
मैंने अतिरिक्त रूप से लिखा है।
asyncioकाफ़ी इस्तेमाल होता है.. और काम का है.. task cancellation के edge-triggered (level-triggered नहीं) होने की एक सीमा है, लेकिन सच कहें तो ऐसा कोड लिखना, जो task cancellation के प्रति aware हो और gracefully handle करे, बहुत आम बात नहीं है। उससे भी बड़ी समस्या यह है कि event loop task के लिए weak reference रखता है, इसलिए वह GC की वजह से गायब हो सकता है.. लेकिन structured concurrency से यह हल हो जाता है.ज़्यादातर प्रमुख i/o कामों के लिए
asyncioसपोर्ट करने वाली लाइब्रेरी ढूँढने में कोई समस्या नहीं होती..GIL? इसका इससे बहुत बड़ा संबंध नहीं है..
asyncioको CPU intensive कामों में parallelism के लिए इस्तेमाल करने का नज़रिया ही थोड़ा अजीब है.. GIL बेहतर होगा तो CPU intensive multithreading में वह उपयोगी होगा.. async का मकसद i/o bottleneck वाले हिस्सों को जितना हो सके उतनी efficiently चलाना है...खैर, निष्कर्ष.. डिज़ाइन के स्तर पर कुछ समस्याएँ ज़रूर हैं, लेकिन लक्ष्य हासिल करने के लिए इसे इस्तेमाल करने में कोई खास दिक्कत नहीं हुई, और production में इसका अच्छे से उपयोग हो रहा है.
MITM अटैक था, फिर भी उन्होंने https कम्युनिकेशन को कैसे डिक्रिप्ट किया? क्या सिर्फ मुझे ही यह नहीं पता?
Biome की तुलना में इसकी स्पीड कैसी होगी?
मैं बस joblib इस्तेमाल करूँगा