काश UI थोड़ा और modern होता..

Windows पर भी इसे scoop के ज़रिए इंस्टॉल किया जा सकता है.

अच्छा है..

Zed AI इंटीग्रेशन पर काफ़ी मेहनत कर रहा है.

Agent Client Protocol (ACP)
Zed - सबसे तेज़ AI code editor
सहयोग के लिए code editor 'Zed', अब open source में बदला

मैं पूरी तरह सहमत हूँ, लेकिन AI 'घृणाकर्ता' कहने के बजाय AI 'अस्वीकारकर्ता' कहना कैसा रहेगा, ऐसा मुझे लगता है। 'घृणा' शब्द में निहित अर्थ और उसका लहजा अच्छा नहीं है, और घृणा हमेशा घृणा को ही जन्म देती है।

अब भी biome ज़्यादा तेज़ है। लेकिन सिर्फ़ स्पीड देखें तो voidzero का oxlint उससे भी तेज़ है.

इस्तेमाल में आसानी और documentation के लिहाज़ से biome ज़्यादा सुविधाजनक है, इसलिए अगर मौजूदा ESLint, ESLint + Prettier की जगह ESLint + ESLint Stylistic के संयोजन के साथ तेज़ होने के साथ-साथ स्थिर भी नहीं होता, तो यह multi-threading optimization भले ही शानदार हो, लेकिन लगता है कि कभी न कभी इसकी जगह कोई और ले सकता है।

धत्त;;

दिलचस्प है

यह Firefox के लिए भी अच्छी खबर है।
अगर Google की वह फंडिंग न हो, जो कम-से-कम दिखावे के लिए यह जताती है कि सब कुछ एक्सक्लूसिव नहीं है, तो Mozilla तुरंत ही डूब जाएगा।
Chrome हाथ से निकल गया तो उसे यह देने की कोई वजह नहीं बचेगी।

लगता है उन्होंने अभी तक यह नहीं सोचा कि React productivity को नुकसान पहुँचाता है।

अगर code बहुत लंबा हो, फिर भी अगर यह आसानी से समझाया जा सके कि "यह क्या करता है", तो वह debt नहीं है.

बात यह है कि AI का बेतहाशा इस्तेमाल इसे मुश्किल बना देता है, इसलिए कहा जाता है कि वह debt पैदा करता है.

उन्होंने संचार को हैक नहीं किया, बल्कि gateway को हैक किया।
गेम server लोड के हिसाब से बढ़ते-घटते रहते हैं,
इसलिए किस server से connect करना है, यह login करते समय gateway बताता है।
आजकल मुफ्त में TLS certificate मिल जाते हैं, इसलिए HTTPS भी सुरक्षित तरीके से सेटअप किया जा सकता है, है ना?

संभवतः बात यह है कि compromised gateway गलत server की ओर इशारा करता है, और वह server सारा data बीच में intercept करके MITM attack करता है.

नीचे लगे Hacker News कमेंट में कही गई बात बिल्कुल सही है.

"Next.js में 99.9999% प्रोजेक्ट्स के लिए अनावश्यक रूप से बहुत बड़ा abstraction layer है, और जिन कुछ मामलों में सच में इसकी ज़रूरत पड़ती भी है, वहाँ भी लो-लेवल components के साथ custom solution बनाना ज़्यादा बेहतर लगता है"

बेकार में ज़रूरत से ज़्यादा complex API, अस्थिर और अधूरा होने के बावजूद लगातार production ready बताकर प्रचार करना, और Vercel पर इतनी भारी निर्भरता कि Vercel के बिना इसे ढंग से ऑपरेट करना भी मुश्किल है.

शायद इसलिए कि मैंने अपना करियर web से शुरू किया था, web में (खासकर front-end में) मूलतः ऐसे ही मज़े(?) के साथ development किया जाता है, हाहा
तेज़ी से बदलते रहने वाला स्वाद...

JS की तरफ़ थोड़ा ऐसा ही लगता है। ऐसी बहुत-सी चीज़ें हैं जिन्हें अच्छा कहा जाता है, लेकिन उनमें से हर एक में थोड़ी-थोड़ी समस्या है, और ट्रेंड के हिसाब से वे बहुत जल्दी बदलती भी रहती हैं...
हो सकता है मुझे ऐसा इसलिए लगता हो, क्योंकि मैंने Java, EJB, Struts को मुख्य रूप से इस्तेमाल किया था।

धन्यवाद।

https://github.com/kelseyhightower/nocode

ऊपरी तौर पर code lines (LOC) की संख्या भी महत्वपूर्ण है। उत्पादकता के लिहाज़ से एक पेज पढ़कर समझना और 3 लाइनें पढ़कर समझना अलग बात है।

बिल्कुल, मैं भी production में .asyncio का बहुत ज़्यादा इस्तेमाल करता हूँ, लेकिन मौजूदा उपयोग अनुभव से मैं इतना संतुष्ट नहीं हूँ कि यह कह सकूँ, 'मैं इसका अच्छी तरह इस्तेमाल कर रहा हूँ।'

मौजूदा asyncio को GIL को आधार मानकर डिज़ाइन किया गया है; एक तरह से देखें तो यह GIL से बचने की रणनीति है, इसलिए GIL सीधे asyncio के साथ इंटरैक्ट नहीं करता।

लेकिन asyncio पर आधारित पूरे concurrency programming के नज़रिए से देखें, तो यह कहना कि GIL अप्रासंगिक है, मुझे कुछ वैसा लगता है जैसे कहना, 'Python है, तो न होना स्वाभाविक है.'