Azure CTO: "अब नए प्रोजेक्ट C/C++ में शुरू करना बंद करने का समय आ गया है"

xguru · 2022-09-21T10:54:46+09:00

अगर ऐसी स्थिति है जहाँ बिना GC वाली भाषा सचमुच ज़रूरी है, तो Rust का उपयोग करें यह सुरक्षा और विश्वसनीयता के लिए है इंडस्ट्री को C/C++ को deprecated language घोषित कर देना चाहिए

(twitter.com/markrussinovich)

22 पॉइंट द्वारा xguru 2022-09-21 | 55 टिप्पणियां | WhatsApp पर शेयर करें

अगर ऐसी स्थिति है जहाँ बिना GC वाली भाषा सचमुच ज़रूरी है, तो Rust का उपयोग करें
यह सुरक्षा और विश्वसनीयता के लिए है
इंडस्ट्री को C/C++ को deprecated language घोषित कर देना चाहिए

55 टिप्पणियां

ahwjdekf 2023-03-01

अब तक Rust की तारीफ़ करते हुए इस्तेमाल करने वाले लोग भी कहते हैं कि async से सामना होते ही अचानक हक़ीक़त समझ में आ जाती है। यहाँ तक कि क्या Rust में लाइब्रेरी भी नहीं बनानी चाहिए (यह बहुत ज़्यादा जटिल, पेचीदा और कठिन है)? ऐसी शिकायतें भी सामने आ रही हैं।

kernel00 2022-10-03

कुछ लोग Mark Russinovich कौन हैं यह जाने बिना ही उन्हें कमतर बता रहे हैं... वे sysinternals tool suite और किताब Windows Internals के लेखक हैं... Windows को reverse engineering करके टूल बनाते-बनाते Microsoft Fellow बने व्यक्ति हैं...

ahwjdekf 2022-09-25

rust के ज़बरदस्त फैन लोगों की समस्याओं पर एक छोटे वीडियो के ज़रिए तंज कसता हुआ लेख

https://twitter.com/cmuratori/status/1367627549816152064?lang=en

ahwjdekf 2022-09-25

Rust के पास अभी तक कोई औपचारिक specification भी नहीं है....

functor 2022-09-29

C++ की औपचारिक spec "मौजूद" तो है, लेकिन सभी implementations (gcc, clang, ...) अधूरे हैं।

lifthrasiir 2022-09-26

यह एक आम तर्क है, लेकिन जिसने वास्तव में बहुत-सी specifications पढ़ी हैं और कई बार implementations भी किए हैं, उसकी नज़र से देखें तो specification है या नहीं, इससे अपने-आप में क्या फ़र्क पड़ता है, यह स्पष्ट नहीं है.

"Specification" की कई strategies होती हैं। एक तरीका है बाहरी तौर पर दिखने वाले behavior को केंद्र में रखकर वर्णन करना, और दूसरा है आंतरिक behavior का वर्णन करना। साथ ही, natural language का उपयोग करना है या machine-readable तरीकों का, जैसे pseudocode या mathematical definition, यह भी अलग होता है। Python या Rust language reference documents जैसी चीज़ें बाहरी behavior को natural language में वर्णित करने वाली specifications हैं। ISO standards आदि में अक्सर दिखने वाला approach आंतरिक behavior को natural language में वर्णित करने वाला specification होता है, लेकिन इस बात की कोई गारंटी नहीं होती कि यह आंतरिक behavior वास्तविक implementations के approach से मेल खाता हो। इसके बजाय, इसे इस तरह परिभाषित किया जाता है कि यदि उस आंतरिक behavior के आधार पर बनी किसी काल्पनिक implementation और वास्तविक implementation का बाहरी तौर पर दिखने वाला behavior observationally equivalent हो, तो उसे standard के अनुरूप माना जाएगा। ECMAScript natural language में लिखा हुआ है, लेकिन उसकी वास्तविक संरचना लगभग pseudocode को natural language में लिख देने जैसी है, और WebAssembly जैसे मामलों में आंतरिक behavior के लिए natural language specification और mathematical definition दोनों दिए जाते हैं.

Implementation के नज़रिए से natural language specifications लगभग सब एक जैसी ही होती हैं। चूँकि natural language specification को वास्तविक implementation से अलग बनाना पड़ता है, इसलिए दोनों के बीच दूरी आ जाना स्वाभाविक है, और गलतियाँ होना भी आम बात है। बाहरी behavior के आधार पर implement करना आसान है या आंतरिक behavior के आधार पर, यह परिस्थिति पर निर्भर करता है; programming language के दृष्टिकोण से किसी एक पक्ष को चुनना अनिवार्य है, ऐसा नहीं है। इस अर्थ में Rust के लिए specification पहले से मौजूद है, और वह इतनी जानकारी देती है कि उसके आधार पर दूसरी वैकल्पिक implementations भी सामने आ सकें.

अगर आप सिर्फ़ इस आधार पर standard की परिपक्वता आँकना चाहते हैं कि वह ISO standard बना है या नहीं, तो मैं आपको यह ख़बर दे सकता हूँ कि मैंने ISO/IEC 18181-1 JPEG XL standard में लगभग 100 bugs ढूँढ़े हैं (और उसी वजह से 2nd amendment में देरी हो रही है)...

xguru 2022-09-25

Hacker News पर भी 800 से ज़्यादा comments आए थे.. यहाँ भी काफ़ी गर्म बहस चल रही है...
https://news.ycombinator.com/item?id=32905885

kayws426 2022-09-25

आपकी मेहनत के लिए बहुत धन्यवाद।
वैसे... मैंने एक लेख देखा था जिसमें कहा गया था कि जब किसी व्यक्ति की पसंदीदा किसी चीज़ पर हमला होता है,
तो उस व्यक्ति की प्रतिक्रिया को समझने की कोशिश करते समय उसे उसके व्यक्तित्व का दोष मान लेने से बचना चाहिए; मुझे लगा यह अच्छी बात है, शायद इसलिए कि वास्तविक स्थिति में ऐसा मन बनाए रखना आसान नहीं होता।

ahwjdekf 2022-09-24

ट्वीट की टिप्पणियों में एक बात काफ़ी प्रभावशाली लगी।

लोग आख़िरकार Rust को "unsafe तरीके" से लिखने लगते हैं। - संक्षेपित - Rust का उद्देश्य कभी भी उन चीज़ों को replace करना नहीं था।

kayws426 2022-09-24

इस मौके पर, मैं एक लिंक जोड़ रहा हूँ जिससे आप जान सकते हैं कि Mark Russinovich कौन हैं।
https://en.m.wikipedia.org/wiki/Mark_Russinovich

ahwjdekf 2022-09-24

एक बात और कहूँगा। जो लोग C++ इस्तेमाल करते हुए बार-बार error करते थे और bug बनाते थे, वही कहते हैं, अरे यह तो इस्तेमाल ही नहीं होता, चलो आजकल लोकप्रिय हो रहे Rust पर चलते हैं... कहते हैं न, memory error की चिंता नहीं करनी पड़ेगी... ऐसे लोग वही के वही हैं। Rust लेकर भी इसी तरह के bug बना लेंगे... फिर कहेंगे, अब अगली कौन-सी language सीखकर देखें? C++ में pointer dereference तक ठीक से न किया हो, वही लोग Rust की अंधी तारीफ़ करते हैं।

ahwjdekf 2022-09-24

उस तरह के लोग Rust जिन ownership, reference, borrowing जैसी चीज़ों को अपनी ताकत बताते हैं, उन्हें compile करते समय error आते हैं और सिरदर्द लगता है, इसलिए वे सबको नज़रअंदाज़ करके बस unsafe मिलाकर ऐसे इस्तेमाल करेंगे जैसे वह C++ हो।

functor 2022-09-29

वैसे भी मरना है, तो जीते ही क्यों हैं?
यह लगभग उसी स्तर की दलील है।

budlebee 2022-09-25

ऐसा लगता है जैसे यह दलील दी जा रही हो कि वैसे भी जो लोग हादसे करते हैं, वे seatbelt भी नहीं पहनते और traffic signal भी नज़रअंदाज़ करते हैं, इसलिए seatbelt और traffic signal का कोई खास मतलब नहीं है।
यह कहा जा सकता है कि जो लोग अच्छे हैं वे कुछ भी करें अच्छा करेंगे, और जो अच्छे नहीं हैं वे कुछ भी करें अच्छा नहीं करेंगे, लेकिन अगर उस तर्क पर जाएँ तो फिर tools की उपयोगिता पर चर्चा ही संभव नहीं रह जाती।

cr543l 2022-09-23

समस्या यह है कि इस भाषा को इस्तेमाल करना बहुत मुश्किल है, लेकिन बात सही ही है।

iolothebard 2022-09-23

जब visual rust आ जाएगा, तब मानूँगा -.-k

binaryeast 2022-09-21

C/C++ अब सचमुच लैटिन जैसी स्थिति की ओर जाते दिख रहे हैं। अकादमिक अध्ययन के लिए इसे किसी न किसी को सीखना तो चाहिए, लेकिन इसमें महारत हासिल करना लगभग असंभव है, और क्योंकि यह एक पुरानी प्रणाली है, आज के नज़रिए से देखें तो इसमें कई अव्यावहारिक पहलू भी हैं...

dalinaum 2022-09-21

यह दिलचस्प है कि लोग उन भाषाओं का तो अच्छी तरह इस्तेमाल करते हैं जिनमें सब कुछ unsafe होता है, लेकिन ऐसी भाषा को क्यों बिल्कुल स्वीकार नहीं करते जिसमें unsafe का इस्तेमाल सीमित रूप से किया जा सकता है।

functor 2022-09-22

मुझे लगता है कि यह Stockholm syndrome का एक प्रकार है।

williameom 2022-09-21

C की भावना

1. प्रोग्रामर पर भरोसा करें।  
2. प्रोग्रामर को वह करने से न रोकें जो किया जाना ज़रूरी है।  
3. भाषा को छोटा और सरल रखें।  
4. किसी ऑपरेशन को करने का केवल एक ही तरीका दें।  
5. इसे तेज़ बनाएं, भले ही इसके पोर्टेबल होने की गारंटी न हो।

functor 2022-09-22

मेरी निजी राय में, मुझे लगता है कि पहली बात से ही यह गलत है lol इंसान जन्म से ही error-prone होता है, इसलिए..

heal9179 2022-09-21

C++ में भी अगर smart pointers और memory pool का सक्रिय रूप से इस्तेमाल करें तो काम चल जाता है..
मेरे हिसाब से, सोचने से कम ही ऐसे मौके आते हैं जब pointers को सीधे handle करना पड़े।

मुझे लगता है कि आखिरकार thread-safe code लिखना programmer की अपनी क्षमता पर निर्भर करता है।
किसी भी language का इस्तेमाल करें,
अगर skill अच्छी न हो, तो या तो safe लेकिन बहुत low-performance code बनता है, या फिर risky code की शक्ल दिखती है।

hiyama 2022-09-23

प्रोग्रामर की क्षमता के भरोसे कार चलाना या हवाई जहाज़ उड़ाना छोड़ देना बहुत डरावना है....

functor 2022-09-22

thread-safe कोड आखिरकार प्रोग्रामर की अपनी क्षमता पर निर्भर करता है <- मुझे यह सोच खतरनाक लगती है, क्योंकि memory / thread safety सिर्फ प्रोग्राम के क्रैश होने या धीमा होने भर का मामला नहीं है, बल्कि यह सुरक्षा संबंधी कमजोरियों में भी बदल सकती है, इसलिए मुझे नहीं लगता कि इसे किसी एक व्यक्ति की क्षमता पर छोड़ देना चाहिए।
इसे पहले से रोकने के लिए कई तरह के तरीकों पर शोध होता रहा है, और वे परिपक्व होकर rust जैसी भाषाओं और अन्य टूल्स के रूप में सामने आए हैं; ऐसे में उनका उपयोग किए बिना सारा दोष व्यक्ति पर डालना ठीक नहीं है, क्योंकि सॉफ़्टवेयर का रोज़मर्रा की ज़िंदगी पर असर अब बहुत बड़ा हो चुका है।

mastotron 2022-09-21

इंसान, आखिर इंसान ही है, इसलिए उससे गलती होना तय है, और चाहे प्रोग्रामर कितना भी होशियार क्यों न हो, उससे भी गलतियाँ होती ही हैं। मेमोरी bugs भी आखिरकार ऐसी ही गलतियों से पैदा होते हैं...

आजकल ऐसा लगता है कि खुद से सब कुछ सही करने पर ज़ोर देने से बेहतर तरीका शायद यह है कि शुरू से ही ऐसा माहौल दिया जाए जहाँ गलती करना मुश्किल हो।

ahwjdekf 2022-09-21

हमारी कंपनी में अगर Rust इस्तेमाल करना है, तो unsafe का इस्तेमाल मना है। ऐसा कोई नियम तो होना ही चाहिए, तभी भाषा-स्तर पर मिलने वाली safety पर एक बार भरोसा करने की बात की जा सकती है। लेकिन क्या यह वाकई व्यावहारिक है?

mastotron 2022-09-21

बिल्कुल, Rust इस्तेमाल करने वाली कंपनियों में आम तौर पर यह सहमति होती है कि जब तक सचमुच ज़रूरी न हो, unsafe का इस्तेमाल नहीं करना चाहिए। उससे भी बढ़कर, मैं आपको सलाह दूँगा कि आप खुद Rust में लिखकर देखें... वास्तव में unsafe इस्तेमाल करने की ज़रूरत कितनी बार पड़ती है, यह शायद आप खुद इस्तेमाल करके ही जान पाएँगे, है न?

ahwjdekf 2023-02-15

tokio जैसी जानी-पहचानी लाइब्रेरीज़ में भी unsafe का भरपूर इस्तेमाल किया गया था

novemberoscar 2022-09-21

काफ़ी सारे कमेंट ऐसे दिख रहे हैं जो इसे All or nothing की तरह देखते हैं—यानी All नहीं है तो उसकी कोई वैल्यू ही नहीं है

यहाँ unsafe / safe को स्पष्ट रूप से अलग-थलग किया जा सकता है, और इससे यह फ़ायदा है कि जो व्यक्ति 100 memory bugs पैदा करता, वह शायद 10 ही करे। लेकिन फिर भी unsafe मौजूद है / फिर भी memory bugs होते हैं => इसलिए यह C++ से बेहतर कुछ नहीं है—ऐसा देखने का नज़रिया क्या वाकई व्यावहारिक आकलन है, इस पर मुझे ख़ुद काफ़ी संदेह है 😅

ruinnel 2022-09-22

टिप्पणियों की संख्या से तो ऐसा लगता है, लेकिन.....
लगता है कि सही स्थिति यह है कि "all or nothing" वाली राय रखने वाले एक व्यक्ति ने बहुत सारी टिप्पणियाँ लिखी हैं...

csjune 2022-09-21

मैं भी इस टिप्पणी से सहमत हूँ। किसी चीज़ को जितना ज़्यादा द्विआधारी नज़रिए से देखते हैं, उतना ही अंत में अपना ही नुकसान होता है.

व्यावहारिक काम में फायदे-नुकसान तौलकर आखिरकार वही चुना जाता है जिसमें कुल मिलाकर सबसे बड़ा + हो। इंडस्ट्री की प्रकृति को देखते हुए, अगर इस समय C/C++ का इस्तेमाल करना मजबूरी न हो, तो Rust इस्तेमाल करने से मिलने वाले फायदे बड़े हैं, इसलिए मुझे लगता है कि धीरे-धीरे उन क्षेत्रों का दायरा बढ़ रहा है जहाँ Rust का उपयोग हो रहा है.

जो लोग Rust की तरफ जा रहे हैं वे कोई बेवकूफ तो हैं नहीं; उन्होंने Rust इस्तेमाल करके देखा होगा, और अगर नतीजे के तौर पर C++ से बेहतर कुछ मिल रहा है, तभी तो वे उसे लगातार इस्तेमाल कर रहे हैं, हाहा

alstjr7375 2022-09-21

कुछ नहीं... सब कुछ

functor 2022-09-21

अब शायद बहुत कम लोग होंगे जो इस बात से असहमत हों कि Rust अगला C++ है। आखिर Linux kernel ने भी इसे एक आधिकारिक भाषा के रूप में अपना लिया है।
लेकिन Rust वाकई इस्तेमाल करने में आसान भाषा है या नहीं, इस पर थोड़ा संदेह है... memory safety की समस्याओं को पहले ही पकड़ने के लिए की जाने वाली static analysis की वजह से compile time काफ़ी भारी पड़ता है, और ownership जैसी semantics कठिन होने के कारण Python या Java जैसी general-purpose भाषाओं की तुलना में इसे सीखने के लिए कहीं अधिक अध्ययन की ज़रूरत होती है।

dalinaum 2022-09-21

कंपाइल टाइम में शायद LLVM खुद ही बड़ी समस्या है। Facebook LLVM के instruction sel को बेहतर बनाने पर काम कर रहा है, इसलिए स्थिति बेहतर होगी।

functor 2022-09-22

खोजकर देखा तो वाकई ऐसा ही है। मुझे लगा था ownership से जुड़े type check पर बहुत समय खर्च होता होगा, लेकिन llvm backend भी काफ़ी बड़ा है..

ahwjdekf 2022-09-21

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

mastotron 2022-09-21

Rust में unsafe आम तौर पर सिर्फ low-level coding के समय ही ज़रूरी होता है; सामान्य application लिखते समय इसका इस्तेमाल लगभग कभी नहीं करना पड़ता।

और अगर unsafe block के अंदर memory से जुड़ी समस्या हो भी जाए, तब भी भाषा स्तर पर यह सुनिश्चित होता है कि समस्या वाला हिस्सा unsafe block के अंदर ही है, इसलिए debugging को आसान बनाने का फायदा भी होता है।

functor 2022-09-21

अगर unsafe होने पर आप पूछेंगे, "इसे क्यों इस्तेमाल करें?", तो फिर शुरुआत से ही C/C++ का इस्तेमाल नहीं करना चाहिए, है ना?

ahwjdekf 2022-09-21

C++ भी लगातार विकसित हो रहा है, और अगर unsafe ही इस्तेमाल करना है तो सीधे C++ ही इस्तेमाल कर लें; ऐसे में अलग से RUST सीखकर उसे इस्तेमाल करने की ज़रूरत महसूस नहीं होती।

functor 2022-09-21

हर Rust प्रोग्रामिंग में unsafe की ज़रूरत नहीं होती।
इतनी सूक्ष्म memory manipulation, जहाँ unsafe की ज़रूरत पड़े, आम तौर पर library development में चली जाती है, इसलिए (जहाँ शायद सबसे ज़्यादा demand होगी) application development के स्तर पर unsafe इस्तेमाल करने की नौबत लगभग नहीं आएगी।
यह सही है कि C++ भी लगातार evolve हो रहा है, लेकिन backward compatibility के लिए legacy का बोझ बहुत दर्दनाक है। अगर आपको सिर्फ unsafe एक चीज़ से ही असंतोष है, तो लगता है कि C++ की लगभग सारी features से भी असंतोष होगा, हाहा

alstjr7375 2022-09-21

इसीलिए unsafe की सिफारिश नहीं की जाती।
safe इस्तेमाल करें तो सब कुछ unsafe जैसा ही होने वाले C/C++ की तुलना में यह अधिक सुरक्षित है।
https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf

ahwjdekf 2022-09-21

अगर unsafe जैसा अस्पष्ट तंत्र न हो, तो शायद Rust, C++ का सचमुच एक वास्तविक विकल्प बन सकता है।

jjpark78 2022-09-21

मुझे लगता है कि अगर FFI थोड़ा और user-friendly होता तो अच्छा रहता.. मैंने FFI के ज़रिए external library के साथ complex structs का आदान-प्रदान करने की कोशिश की थी, और याद है कि वह काफ़ी दर्दनाक अनुभव था।

alstjr7375 2022-09-21

यहाँ तक कि Rust से Rust में भी काम आसान नहीं है..
https://github.com/rodrimati1992/abi_stable_crates

jjpark78 2022-09-21

MS द्वारा Rust को सक्रिय रूप से सपोर्ट किए जाने की स्थिति की निरंतरता में देखें, तो यह काफी स्वाभाविक बयान लगता है.

colus001 2022-09-21

उस ज़िद्दी Torvalds ने भी Rust अपना लिया है, तो मुझे नहीं लगता कि ऐसी भाषा को ज़बरदस्ती इस्तेमाल करते रहने की ज़रूरत है जिसे सीखने वाले लोग भी कम होते जा रहे हैं।

ahwjdekf 2022-09-21

मेमोरी से जुड़े bugs सिर्फ Rust इस्तेमाल करने से कभी पूरी तरह गायब नहीं होते। bugs बनाने वाले लोग किसी भी language में bugs की भरमार कर देंगे। C++ को बिना किसी समस्या के efficiently अच्छी तरह इस्तेमाल किया जा रहा है, तो फिर उसे खत्म करने की क्या बात है। सच में, यह तो जैसे जंग छेड़ देने वाली धमाकेदार टिप्पणी यूँ ही कर दी गई।

functor 2022-09-21

यह कहना कि C/C++ को बिना किसी समस्या के कुशलता से इस्तेमाल किया जा रहा है, मुश्किल है, क्योंकि ऐतिहासिक रूप से C/C++ में मेमोरी से जुड़े अनगिनत बग फूट चुके हैं, और शायद अभी भी कहीं न कहीं फूट रहे होंगे। (हालांकि इसकी बदौलत कई PL/SE शोधकर्ताओं का गुज़ारा चलता रहा है।)
Microsoft की घोषणा के अनुसार, सुरक्षा बगों में 70% मेमोरी से जुड़े बग हैं (https://zdnet.com/article/…)
Chromium प्रोजेक्ट की जांच में भी यही बात सामने आई (https://www.chromium.org/Home/chromium-security/memory-safety/), और वहां भी लगभग 70% बग मेमोरी से जुड़े थे.

jjpark78 2022-09-21

मैंने कहीं एक पुराना लेख देखा था जिसमें कहा गया था कि Windows kernel bugs में से ज़्यादातर memory-related errors होते हैं,
और जिन हिस्सों को Rust में develop किया जा रहा है, उनमें ऐसे errors नाटकीय रूप से कम हो गए हैं..

भाषा की मूल डिजाइन ही readonly को सक्रिय रूप से प्रोत्साहित करती है, इसलिए C++ की तुलना में इसकी language design ज़्यादा सुरक्षित है—इसे नकारना मुश्किल लगता है। हालांकि इसी वजह से ownership जैसा पहले कभी न सुना गया concept सामने आता है, जिससे programming मुश्किल हो जाती है।

और performance के लिहाज़ से यह फायदा भी है कि बहुत अच्छी तरह designed C++ code की तुलना में भी roughly लिखे गए Rust code के सांख्यिकीय रूप से ज़्यादा तेज़ चलने की संभावना होती है।

lordang 2022-09-21

लगता है उन्होंने कुछ ऐसी बात कह दी है जिस पर काफ़ी हंगामा हो सकता है. हाहा
व्यक्तिगत रूप से मुझे लगता है कि C++ अब इतना पुराना हो चुका है कि backward compatibility की वजह से यह बंध गया है, इसलिए इसका modern तरीके से विकास धीमा है.
और backward compatibility को पूरी तरह बनाए रखते हुए modern चीज़ें जोड़ने के कारण, एक ही काम करने के बहुत सारे तरीके हो गए हैं, जो नए लोगों के लिए और भी बड़ा entry barrier बनते हैं.
मुझे भी अब C++ की तुलना में Rust बेहतर लगता है. memory management से जुड़े bugs ढूंढ़ते-ढूंढ़ते आँखें लाल हो जाने वाले दिन अब खत्म होने चाहिए.

jjpark78 2022-09-21

हाँ, सही है.. अगर कोई development project पूरी तरह शून्य से शुरू हो रहा है, तो खास तौर पर C++ चुनने की कोई वजह नहीं है..

kandk 2022-09-21

पूरी तरह सहमत

loblue 2022-09-22

Rust इस्तेमाल करना चाहूँ भी तो फिलहाल उसे बस सहायक तौर पर ही इस्तेमाल कर पाता हूँ, कामकाज में अभी उसका इस्तेमाल करने की नौबत नहीं आती।
इसलिए उससे आसानी से परिचय भी नहीं हो पाता, और थोड़ी देर हाथ से छूट जाए तो भूल भी जाता हूँ...
यकीनन पसंद है इसलिए इस्तेमाल करना चाहता हूँ... हा

koreacglee 2022-09-23

जिन्होंने heap usability की efficiency के लिए एक memory pool तक कभी लिखकर नहीं देखा, वही Rust की रट सबसे ज़्यादा लगा रहे हैं, हाह. Azure CTO कोई ऐसा मत नहीं है जो पूरे industry standard का प्रतिनिधित्व करता हो; और Microsoft तक सीमित करके देखें तब भी यह बिल्कुल Microsoft की आधिकारिक राय नहीं है। बस अचानक क्या सूझा कि अपनी निजी सोच बकते जा रहे हैं... जो लोग C++ ठीक से नहीं कर पाते, क्या वे Rust सही से कर लेंगे? खैर, ऐसी बड़ी-बड़ी बातें बनाने वालों से भरा पड़ा है।

functor 2022-09-26

आपकी बोलचाल से ही आपकी अभद्रता बिना किसी लाग-लपेट के सामने आ जाती है। हिम्मत बनाए रखें।

Azure CTO: "अब नए प्रोजेक्ट C/C++ में शुरू करना बंद करने का समय आ गया है"

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

55 टिप्पणियां