> सोच रहा हूँ कि क्या किसी ने ClickHouse और StarRocks की तुलना की है; कुछ महीने पहले StarRocks का join performance बेहतर लग रहा था https://d2.naver.com/helloworld/1168674
आह, मेरा इरादा OpenAI के future vision या Browser+AI की बेहतर innovation को कमतर दिखाने का नहीं है.
मैं जो कहना चाहता हूँ वह यह है कि अगर OpenAI उस दिशा में कोशिश करता है, तो Chromium या Firefox जैसे major browsers खुले रूप में उपलब्ध हैं, इसलिए development के लिए अलग से acquisition की ज़रूरत वाली स्थिति नहीं लगती।
तकनीकी moat बनाने में acquisition अनिवार्य नहीं है।
इसलिए, अगर acquisition पर विचार किया जाए, तो मुझे लगता है कि तकनीकी पहलू से ज़्यादा market share के ज़रिए expansion उसका मुख्य कारण होगा।
अगर सिर्फ Chromium-आधारित नया browser लॉन्च किया जाए, तो Chrome से न हटने वाले users के लिए उसमें बहुत बड़ा merit नहीं होगा, लेकिन अगर Chrome का acquisition हो जाए, तो browser market के 70% हिस्से वाले users को official update के ज़रिए उसकी AI model services का अनुभव कराया जा सकता है। नई services के विस्तार की बाधा नाटकीय रूप से कम हो जाती है।
जैसा आपने कहा, Edge का विस्तार न कर पाना भी मुझे इसी संदर्भ में दिखता है। Browser market वास्तव में बहुत conservative है। मुझे लगता है OpenAI भी इसी बात को ध्यान में रखकर Chrome acquisition पर विचार कर रहा है। इसलिए OpenAI के "AI-प्रेरित web browsing" खोलने की बात में, OpenAI की क्षमता से ज़्यादा Chrome market का प्रभाव बड़ा लगता है।
Supabase की खासियत यह है कि यह CRUD-आधारित सिस्टम के लिए उपयुक्त है, और API server को develop/operate किए बिना भी frontend से CRUD implement किया जा सकता है, इसलिए backend development का बोझ कम होता है. Frontend और backend developers API spec की जगह table definitions के ज़रिये communicate करते हैं, और features में web console, authentication, और object storage का सबसे ज़्यादा उपयोग हो रहा है.
क्योंकि frontend DB table, view, और function definitions पर निर्भर करता है, इसलिए data change tracking पर थोड़ा ध्यान देना पड़ता है. अगर आपको server-side logic चाहिए, तो मेरा मानना है कि अलग से WAS/REST API बनाना बेहतर रहेगा.
यह एक ऐसी सेवा है जो मुझे बहुत पसंद है। जटिल backend/DB setup के बिना सिर्फ frontend के सहारे भी सेवा बनाई जा सकती है।
मैं इसे वास्तव में अपनी सेवा में इस्तेमाल करने के लिए काफी मेहनत से उपयोग कर रहा हूँ, और मुझे तो developer experience के मामले में यह Firebase से भी बेहतर लगा।
इसमें Korea region भी है, और काफी उदार free tier मिलता है, इसलिए अच्छा लगता है। self-hosting भी की जा सकती है।
Series D फंडिंग मिली है, यह अच्छी खबर है! लेकिन जैसा कि टिप्पणियों में बार-बार कहा गया है, यह एक sustainable business है या नहीं, इसे लेकर थोड़ी चिंता जरूर होती है।
मेरी निजी राय में vendor की serverless service का उपयोग करना जोखिमभरा है, लेकिन containers का उपयोग करके कंपनी द्वारा खुद serverless environment उपलब्ध कराना अच्छा लगता है। अगर serverless को service नहीं बल्कि एक concept के रूप में इस्तेमाल किया जाए, तो यह अच्छा हो सकता है।
कंप्यूटिंग तकनीक के प्रति जुनून के साथ काम करने वाले लोग भी बहुत हैं। अपने विचारों और अनुभवों के आधार पर सामान्यीकरण मत कीजिए। क्योंकि यह उन लोगों के लिए अपमानजनक है।
पहले की तुलना में अब एक व्यक्ति को संभालने वाले काम का दायरा बहुत बढ़ गया है, और इससे समस्याएँ पैदा होती हैं.
•यह सही है कि पहले की तुलना में अब एक इंजीनियर से अपेक्षाएँ कहीं अधिक व्यापक और बड़ी हो गई हैं। और पहले की तुलना में वास्तविक दुनिया का बहुत बड़ा हिस्सा कंप्यूटर सिस्टम के भीतर आ गया है, इसलिए abstraction और implementation की कठिनाई भी तेज़ी से बढ़ रही है। सिर्फ इसलिए कि हम वास्तविक दुनिया के और भी कठिन कामों की सूची गिना सकते हैं, क्या यह ज़रूरी है कि हम यह दावा करें कि यह काम कठिन नहीं है... ऐसा मुझे नहीं लगता।
•शीर्षक का अनुवाद "पागलपन" के रूप में किया गया है, लेकिन मुझे लगता है कि यह बस मौजूदा स्थिति को व्यक्त करता है जो इंसान को बेदम कर देती है। और मैं भी मुख्य लेख की बातों से कुछ हद तक सहमत हूँ। यह सही है कि पहले की तुलना में अब एक इंजीनियर से अपेक्षाएँ कहीं अधिक व्यापक और बड़ी हो गई हैं। और पहले की तुलना में वास्तविक दुनिया का बहुत बड़ा हिस्सा कंप्यूटर सिस्टम के भीतर आ गया है, और उसी अनुपात में abstraction और implementation की कठिनाई भी तेज़ी से बढ़ रही है। सिर्फ़ वास्तविक दुनिया के और कठिन कामों की सूची गिनाने से यह कहने की ज़रूरत है क्या कि यह काम कठिन नहीं है...
वो तो बिल्कुल अलग उदाहरण है, है ना? rollback कर देने से सब खत्म हो जाता है? आपका अपना अनुभव ही सब कुछ नहीं होता। क्या आपने कभी बड़े पैमाने का काम नहीं किया है?
•ऐसा लगता है कि आप SW development को सिर्फ code generation और API generation समझ रहे हैं। लेकिन SW development का असली सार वास्तविक दुनिया को abstract करके protocol और interface बनाना, और चीज़ों को उनमें फिट करना है। मतलब, अलग-अलग तरीकों से काम करने वाली चीज़ों को जोड़कर उन्हें ऐसे चलाना कि वे एक ही सिस्टम की तरह काम करें। यह सोच से कहीं अधिक जटिल बौद्धिक काम है, और इसी वजह से जितना लोग समझते हैं उससे कहीं अधिक मुश्किल है अच्छे SW engineer तैयार करना। अभी कहा जाता है कि लोग बहुत हैं, लेकिन उनमें से वास्तव में ठीक से काम कर सकने वाले कितने हैं? ज़्यादातर ने बस कोई tool एक-दो बार इस्तेमाल किया होता है, लेकिन वही SW engineer होने का मूल नहीं है।
•क्या इसकी सीधे manufacturing industry से तुलना करना सार्थक है? जिस नज़रिए से देखें कि industry अभी पर्याप्त रूप से उन्नत नहीं हुई है, उस हिसाब से तुलना का विषय manufacturing लगता है। लेकिन अगर software industry को manufacturing के paradigm से समझने की कोशिश करेंगे, तो यह handcraft या hobby development जैसा दिख सकता है; उल्टा, मुझे लगता है कि ऐसे ही पहलू software development की अपनी लचीली और रचनात्मक संस्कृति बनाते हैं, और उसी के आधार पर यह आगे बढ़ रहा है.
•यह सही है कि पहले की तुलना में अब एक engineer से अपेक्षाएँ कहीं अधिक व्यापक और बड़ी हो गई हैं। और पहले की तुलना में वास्तविक दुनिया का बहुत बड़ा हिस्सा computer systems के भीतर आ गया है, इसलिए abstraction और implementation की कठिनाई भी तेज़ी से बढ़ रही है। सिर्फ़ इसलिए कि हम वास्तविक दुनिया के और भी कठिन कामों की सूची गिना सकते हैं, क्या यह कहना ज़रूरी है कि यह काम कठिन नहीं है... मुझे ऐसा नहीं लगता।
•परिस्थितियाँ बदल गई हैं। मुझे नहीं लगता कि बाज़ार में developers से अपेक्षाएँ और उन्हें मिलने वाला reward पहले से ज़्यादा होने का कारण सिर्फ़ उनकी technology, skill level या expertise है। जैसे-जैसे IT मानव जीवन में गहराई से समाता गया है, software की अहमियत बढ़ी है, और वह बहुत-सी infrastructure को संभाल रहा है। मेरा मानना है कि हर developer की क्षमता बढ़ जाने की वजह से reward नहीं बढ़ा, बल्कि यह काम ख़ुद ही महँगा हो गया है। क्योंकि इसकी अहमियत पहले से अधिक हो गई है।
नीचे उचित आलोचनाएँ हैं। computing technology की accessibility ज़्यादा होने में SW engineers का योगदान भी बड़ा है। accessibility ज़्यादा होने का मतलब यह नहीं कि professional बनना भी आसान है। क्या cooking तक पहुँच आसान होने से cooking expert बनना आसान हो जाता है?
•सीखना आसान है। मानता हूँ, लेकिन entry barrier कम होने का मतलब यह नहीं कि specialization भी कम है। दूसरे industries, खासकर manufacturing के अन्य technical roles की तुलना में इसे सीखना आसान लगने की वजह शायद development खुद आसान होना नहीं, बल्कि open source culture या कम risk होना है। पहले बताई गई developers की diversity के पहलू में, कुछ काम ऐसे होते हैं जिन्हें जल्दी सीखकर किया जा सकता है, और कुछ काम ऐसे होते हैं जिन्हें expertise के आधार पर करना पड़ता है।
•थोड़ी drawing सीखकर अगर कोई comic artist का assistant बन जाए, तो क्या आप खुद को professional कहते फिरेंगे? या फिर कुछ cooking classes करके kitchen में नौकरी मिल जाए, तो क्या आप खुद को cooking expert, chef कहेंगे? आपकी बात लगभग उसी स्तर की है। अगर यह इतना आसान होता, तो उसे professional नहीं कहा जाता।
Spring में development करते समय सबसे मुश्किल चीज़ों में से एक शायद dependency cycle थी..
एक-दूसरे को अनंत बार initialize करते हुए memory leak से crash हो जाने वाली वह घुटन...
आप संदर्भ से हटकर आलोचना कर रहे हैं। मूल पोस्ट लिखने वाले ने किसी को नीचा नहीं दिखाया, लेकिन SW engineer role की value को कमतर दिखाकर और उसे गिराकर पेश करने वाले क्या आप खुद नहीं हैं?
> सोच रहा हूँ कि क्या किसी ने ClickHouse और StarRocks की तुलना की है; कुछ महीने पहले StarRocks का join performance बेहतर लग रहा था
https://d2.naver.com/helloworld/1168674
5 साल पहले जब इसका public beta शुरू हुआ था, तब मैंने इस पर एक लेख पोस्ट किया था और co-founder आकर एक comment भी छोड़ गए थे; इस दौरान यह वाकई बहुत बढ़ गया है haha
Supabase public beta की शुरुआत - open source Firebase विकल्प
आह, मेरा इरादा OpenAI के future vision या Browser+AI की बेहतर innovation को कमतर दिखाने का नहीं है.
मैं जो कहना चाहता हूँ वह यह है कि अगर OpenAI उस दिशा में कोशिश करता है, तो Chromium या Firefox जैसे major browsers खुले रूप में उपलब्ध हैं, इसलिए development के लिए अलग से acquisition की ज़रूरत वाली स्थिति नहीं लगती।
तकनीकी moat बनाने में acquisition अनिवार्य नहीं है।
इसलिए, अगर acquisition पर विचार किया जाए, तो मुझे लगता है कि तकनीकी पहलू से ज़्यादा market share के ज़रिए expansion उसका मुख्य कारण होगा।
अगर सिर्फ Chromium-आधारित नया browser लॉन्च किया जाए, तो Chrome से न हटने वाले users के लिए उसमें बहुत बड़ा merit नहीं होगा, लेकिन अगर Chrome का acquisition हो जाए, तो browser market के 70% हिस्से वाले users को official update के ज़रिए उसकी AI model services का अनुभव कराया जा सकता है। नई services के विस्तार की बाधा नाटकीय रूप से कम हो जाती है।
जैसा आपने कहा, Edge का विस्तार न कर पाना भी मुझे इसी संदर्भ में दिखता है। Browser market वास्तव में बहुत conservative है। मुझे लगता है OpenAI भी इसी बात को ध्यान में रखकर Chrome acquisition पर विचार कर रहा है। इसलिए OpenAI के "AI-प्रेरित web browsing" खोलने की बात में, OpenAI की क्षमता से ज़्यादा Chrome market का प्रभाव बड़ा लगता है।
मैं इसे अपने personal projects में बहुत अच्छी तरह इस्तेमाल कर रहा हूँ।
अचानक Godot...?!
Supabase की खासियत यह है कि यह CRUD-आधारित सिस्टम के लिए उपयुक्त है, और API server को develop/operate किए बिना भी frontend से CRUD implement किया जा सकता है, इसलिए backend development का बोझ कम होता है. Frontend और backend developers API spec की जगह table definitions के ज़रिये communicate करते हैं, और features में web console, authentication, और object storage का सबसे ज़्यादा उपयोग हो रहा है.
क्योंकि frontend DB table, view, और function definitions पर निर्भर करता है, इसलिए data change tracking पर थोड़ा ध्यान देना पड़ता है. अगर आपको server-side logic चाहिए, तो मेरा मानना है कि अलग से WAS/REST API बनाना बेहतर रहेगा.
जो लोग side project करना चाहते हैं, उन्हें मैं हमेशा Supabase को पहला विकल्प recommend करता हूँ। उम्मीद है कि Supabase और भी अच्छा करे!
यह एक ऐसी सेवा है जो मुझे बहुत पसंद है। जटिल backend/DB setup के बिना सिर्फ frontend के सहारे भी सेवा बनाई जा सकती है।
मैं इसे वास्तव में अपनी सेवा में इस्तेमाल करने के लिए काफी मेहनत से उपयोग कर रहा हूँ, और मुझे तो developer experience के मामले में यह Firebase से भी बेहतर लगा।
इसमें Korea region भी है, और काफी उदार free tier मिलता है, इसलिए अच्छा लगता है। self-hosting भी की जा सकती है।
Series D फंडिंग मिली है, यह अच्छी खबर है! लेकिन जैसा कि टिप्पणियों में बार-बार कहा गया है, यह एक sustainable business है या नहीं, इसे लेकर थोड़ी चिंता जरूर होती है।
मेरी निजी राय में vendor की serverless service का उपयोग करना जोखिमभरा है, लेकिन containers का उपयोग करके कंपनी द्वारा खुद serverless environment उपलब्ध कराना अच्छा लगता है। अगर serverless को service नहीं बल्कि एक concept के रूप में इस्तेमाल किया जाए, तो यह अच्छा हो सकता है।
"केला चाहिए था, लेकिन पूरा जंगल उठा लाए" — यह बात वाकई बहुत मज़ेदार है।
ज़रा ध्यान से सोचिए कि दूसरे लोग इसकी इतनी आलोचना क्यों कर रहे हैं, और आप खुद भी या आगे चलकर घमंड में ऐसी बकवास बातें करते हुए मत घूमिए।
कंप्यूटिंग तकनीक के प्रति जुनून के साथ काम करने वाले लोग भी बहुत हैं। अपने विचारों और अनुभवों के आधार पर सामान्यीकरण मत कीजिए। क्योंकि यह उन लोगों के लिए अपमानजनक है।
पहले की तुलना में अब एक व्यक्ति को संभालने वाले काम का दायरा बहुत बढ़ गया है, और इससे समस्याएँ पैदा होती हैं.
•यह सही है कि पहले की तुलना में अब एक इंजीनियर से अपेक्षाएँ कहीं अधिक व्यापक और बड़ी हो गई हैं। और पहले की तुलना में वास्तविक दुनिया का बहुत बड़ा हिस्सा कंप्यूटर सिस्टम के भीतर आ गया है, इसलिए abstraction और implementation की कठिनाई भी तेज़ी से बढ़ रही है। सिर्फ इसलिए कि हम वास्तविक दुनिया के और भी कठिन कामों की सूची गिना सकते हैं, क्या यह ज़रूरी है कि हम यह दावा करें कि यह काम कठिन नहीं है... ऐसा मुझे नहीं लगता।
उसकी तुलना करने की ज़रूरत नहीं है.
•शीर्षक का अनुवाद "पागलपन" के रूप में किया गया है, लेकिन मुझे लगता है कि यह बस मौजूदा स्थिति को व्यक्त करता है जो इंसान को बेदम कर देती है। और मैं भी मुख्य लेख की बातों से कुछ हद तक सहमत हूँ। यह सही है कि पहले की तुलना में अब एक इंजीनियर से अपेक्षाएँ कहीं अधिक व्यापक और बड़ी हो गई हैं। और पहले की तुलना में वास्तविक दुनिया का बहुत बड़ा हिस्सा कंप्यूटर सिस्टम के भीतर आ गया है, और उसी अनुपात में abstraction और implementation की कठिनाई भी तेज़ी से बढ़ रही है। सिर्फ़ वास्तविक दुनिया के और कठिन कामों की सूची गिनाने से यह कहने की ज़रूरत है क्या कि यह काम कठिन नहीं है...
वो तो बिल्कुल अलग उदाहरण है, है ना? rollback कर देने से सब खत्म हो जाता है? आपका अपना अनुभव ही सब कुछ नहीं होता। क्या आपने कभी बड़े पैमाने का काम नहीं किया है?
•ऐसा लगता है कि आप SW development को सिर्फ code generation और API generation समझ रहे हैं। लेकिन SW development का असली सार वास्तविक दुनिया को abstract करके protocol और interface बनाना, और चीज़ों को उनमें फिट करना है। मतलब, अलग-अलग तरीकों से काम करने वाली चीज़ों को जोड़कर उन्हें ऐसे चलाना कि वे एक ही सिस्टम की तरह काम करें। यह सोच से कहीं अधिक जटिल बौद्धिक काम है, और इसी वजह से जितना लोग समझते हैं उससे कहीं अधिक मुश्किल है अच्छे SW engineer तैयार करना। अभी कहा जाता है कि लोग बहुत हैं, लेकिन उनमें से वास्तव में ठीक से काम कर सकने वाले कितने हैं? ज़्यादातर ने बस कोई tool एक-दो बार इस्तेमाल किया होता है, लेकिन वही SW engineer होने का मूल नहीं है।
•क्या इसकी सीधे manufacturing industry से तुलना करना सार्थक है? जिस नज़रिए से देखें कि industry अभी पर्याप्त रूप से उन्नत नहीं हुई है, उस हिसाब से तुलना का विषय manufacturing लगता है। लेकिन अगर software industry को manufacturing के paradigm से समझने की कोशिश करेंगे, तो यह handcraft या hobby development जैसा दिख सकता है; उल्टा, मुझे लगता है कि ऐसे ही पहलू software development की अपनी लचीली और रचनात्मक संस्कृति बनाते हैं, और उसी के आधार पर यह आगे बढ़ रहा है.
•यह सही है कि पहले की तुलना में अब एक engineer से अपेक्षाएँ कहीं अधिक व्यापक और बड़ी हो गई हैं। और पहले की तुलना में वास्तविक दुनिया का बहुत बड़ा हिस्सा computer systems के भीतर आ गया है, इसलिए abstraction और implementation की कठिनाई भी तेज़ी से बढ़ रही है। सिर्फ़ इसलिए कि हम वास्तविक दुनिया के और भी कठिन कामों की सूची गिना सकते हैं, क्या यह कहना ज़रूरी है कि यह काम कठिन नहीं है... मुझे ऐसा नहीं लगता।
•परिस्थितियाँ बदल गई हैं। मुझे नहीं लगता कि बाज़ार में developers से अपेक्षाएँ और उन्हें मिलने वाला reward पहले से ज़्यादा होने का कारण सिर्फ़ उनकी technology, skill level या expertise है। जैसे-जैसे IT मानव जीवन में गहराई से समाता गया है, software की अहमियत बढ़ी है, और वह बहुत-सी infrastructure को संभाल रहा है। मेरा मानना है कि हर developer की क्षमता बढ़ जाने की वजह से reward नहीं बढ़ा, बल्कि यह काम ख़ुद ही महँगा हो गया है। क्योंकि इसकी अहमियत पहले से अधिक हो गई है।
नीचे उचित आलोचनाएँ हैं। computing technology की accessibility ज़्यादा होने में SW engineers का योगदान भी बड़ा है। accessibility ज़्यादा होने का मतलब यह नहीं कि professional बनना भी आसान है। क्या cooking तक पहुँच आसान होने से cooking expert बनना आसान हो जाता है?
•सीखना आसान है। मानता हूँ, लेकिन entry barrier कम होने का मतलब यह नहीं कि specialization भी कम है। दूसरे industries, खासकर manufacturing के अन्य technical roles की तुलना में इसे सीखना आसान लगने की वजह शायद development खुद आसान होना नहीं, बल्कि open source culture या कम risk होना है। पहले बताई गई developers की diversity के पहलू में, कुछ काम ऐसे होते हैं जिन्हें जल्दी सीखकर किया जा सकता है, और कुछ काम ऐसे होते हैं जिन्हें expertise के आधार पर करना पड़ता है।
•थोड़ी drawing सीखकर अगर कोई comic artist का assistant बन जाए, तो क्या आप खुद को professional कहते फिरेंगे? या फिर कुछ cooking classes करके kitchen में नौकरी मिल जाए, तो क्या आप खुद को cooking expert, chef कहेंगे? आपकी बात लगभग उसी स्तर की है। अगर यह इतना आसान होता, तो उसे professional नहीं कहा जाता।
Spring में development करते समय सबसे मुश्किल चीज़ों में से एक शायद dependency cycle थी.. एक-दूसरे को अनंत बार initialize करते हुए memory leak से crash हो जाने वाली वह घुटन...
आप संदर्भ से हटकर आलोचना कर रहे हैं। मूल पोस्ट लिखने वाले ने किसी को नीचा नहीं दिखाया, लेकिन SW engineer role की value को कमतर दिखाकर और उसे गिराकर पेश करने वाले क्या आप खुद नहीं हैं?