भविष्य WinRT या मूल निवासी 2.0

डायरेक्टएक्स के लिए सबसे तेज और सबसे पूर्ण .NET रैपर के निर्माता, अलेक्जेंडर मुटेल, जो केवल विंडोज 8 मेट्रो का समर्थन कर रहा है, फ्रेंच डेमो ग्रुप फ्रिक्वेंसी के एक सदस्य, सिलिकॉनस्टीडियो पर गेम इंजन के आर एंड डी डेवलपर के रूप में काम करता है।

हाल ही में, हम जावा और .NET जैसी प्रबंधित भाषाओं के युग के बाद "गोइंग नेटिव" के विचार की वापसी के बारे में बहुत शोर सुन रहे हैं। पिछले साल, जब WinRT को पेश किया गया था, तब न तो बहुत दूर की टिप्पणियां दिखाई देने लगीं, जिसमें दावा किया गया कि .NET मर चुका था और C ++ अपने सभी महिमा में लौट रहा था - अनुप्रयोगों को विकसित करने का सही और एकमात्र सही तरीका, जबकि JIT शुरू हो रहा था स्क्रिप्टिंग भाषाओं की दुनिया में अधिक से अधिक दिखाई देते हैं (जावास्क्रिप्ट सबसे सक्रिय रूप से जेआईटी के फायदे का उपयोग करता है)। कोई भी कोड एक रास्ता या दूसरा निष्पादन से पहले देशी हो जाएगा - एकमात्र अंतर उस पथ की लंबाई है जिसे वह मूल बनने के लिए जाएगा, और यह कितना अनुकूलित होगा। "देशी" शब्द का अर्थ थोड़ा बदल गया है और शब्द "प्रदर्शन" के साथ अटूट रूप से जुड़ गया है। यहां तक ​​कि प्रबंधित भाषा [C #] के एक मजबूत प्रमोटर के रूप में, इसका प्रदर्शन वास्तव में एक लिखित C ++ एप्लिकेशन से कम है। यह पता चला है कि हमें इस तथ्य को स्वीकार करना चाहिए और C ++ पर वापस लौटना चाहिए, जब WinRT जैसी चीजें हमारे लिए क्रॉस-लैंग्वेज इंटरैक्शन का आधार होंगी? सच में, मैं चाहूंगा कि .NET मर जाए, और यह पोस्ट क्यों और क्यों के बारे में है।

नियंत्रित भाषाओं का युग

आइए प्रबंधित भाषाओं में विकास के हालिया इतिहास की समीक्षा करें और वर्तमान मुद्दों पर प्रकाश डालें। स्लोगन जावा याद है? "हर जगह एक बार लिखो।" यह एक नए प्रतिमान की शुरूआत थी जब पूरी तरह से "सुरक्षित" आभासी मशीन भाषा, एपीआई के एक समृद्ध सेट के साथ मिलकर, किसी भी ओएस और प्लेटफॉर्म के लिए आसानी से एप्लिकेशन विकसित करने का अवसर प्रदान करेगी। यह नियंत्रित भाषाओं के युग की शुरुआत थी। जबकि जावा को विभिन्न विकास उद्योगों में काफी सफलतापूर्वक अपनाया गया था, यह कई डेवलपर्स द्वारा भी खारिज कर दिया गया था जो स्मृति प्रबंधन की सुविधाओं से अवगत थे, अपर्याप्त रूप से अनुकूलित जेआईटी (हालांकि तब से सब कुछ में काफी सुधार हुआ है), बड़ी संख्या में खराब वास्तुशिल्प समाधान, जैसे कि कमी संरचनाओं के लिए समर्थन, मेमोरी तक सीधे पहुंच, और जेएनआई के माध्यम से मूल कोड में कॉल बेहद अक्षम और समय लेने वाली थीं (और यहां तक ​​कि हाल ही में, उन्होंने सभी मूल प्रकार की वस्तुओं को हटाने और बनाने की संभावना पर विचार किया एल सभी वस्तु - क्या एक भयानक विचार!)।

इसके अलावा, जावा स्वयं स्लोगन में किए गए वादे को पूरा नहीं कर सका - वास्तव में, प्रत्येक प्लेटफ़ॉर्म की सभी क्षमताओं को एक एकल एपीआई के साथ कवर करना असंभव है, जिसके कारण स्विंग जैसी चीज़ों को हल्के ढंग से रखा गया, न कि सबसे इष्टतम यूआई फ्रेमवर्क। इसके अलावा, जावा मूल रूप से एक एकल प्रोग्रामिंग भाषा के लिए डिज़ाइन किया गया था, हालांकि कई ने JIT और बाईटेकोड में जावा JVM के लिए स्क्रिप्टिंग भाषाओं को पोर्ट करने की क्षमता देखी।

प्रबंधित भाषाओं के युग की शुरुआत में, Microsoft ने भाषा के लिए अपने स्वयं के एक्सटेंशन के साथ जावा बाजार में प्रवेश करने की कोशिश की (हर कोई इस कहानी के अंत के बारे में जानता है) और अंततः प्रबंधित भाषाओं के लिए अपना स्वयं का मंच हासिल किया, जिसे कुछ पहलुओं में बेहतर तरीके से डिजाइन और निर्मित किया गया था: क्वेटोड, कीवर्ड के साथ शुरू असुरक्षित, देशी कोड, हल्के लेकिन बहुत कुशल जेआईटी और एनजीएन को कॉल करते हुए, तेजी से बढ़ती सी #, सी ++ / सीएलआई भाषा, आदि। प्रारंभ में, इंटरलेन्गुएज इंटरैक्शन पर विचार और जावा स्लोगन के बोझ के बिना (हालांकि मैकओएस या मूनलाइट पर सिल्वरलाइट खराब नहीं था। प्रयास)।

दोनों प्लेटफार्मों ने एक समान अखंड स्टैक का उपयोग किया: मेटाडेटा, बायटेकोड, जेआईटी और कचरा कलेक्टर - यह सब निकट से संबंधित है। तदनुसार, समान प्रदर्शन समस्याएं थीं: जेआईटी का तात्पर्य स्टार्टअप में देरी है, और कोड निष्पादन उतना तेज़ नहीं है जितना कि होना चाहिए। मुख्य कारण:

• J ++ C ++ -O2 की तुलना में अपर्याप्त अनुकूलन करता है क्योंकि यह कोड बहुत जल्दी उत्पन्न होना चाहिए (जावा हॉटस्पॉट JVM के विपरीत, .NET JIT मौजूदा कोड को मक्खी पर अधिक अनुकूलित कोड से बदल नहीं सकता है)।
• एईआर प्रकार, जैसे कि एरे, हमेशा एक्सेस पर बॉर्डर चेक करते हैं (सरल लूप की गिनती नहीं, जहां जेआईटी चेक को हटा सकता है यदि लूप समाप्ति की स्थिति सरणी की लंबाई से कम या बराबर है)।
• असेंबली के दौरान कचरा संग्रहकर्ता सभी थ्रेड्स को रोकता है (हालाँकि .NET 4.5 में नए कचरा संग्रहकर्ता ने इस संबंध में कुछ सुधार किया है), जिससे अप्रत्याशित प्रदर्शन ड्रॉप हो सकते हैं।

लेकिन इस तरह के खराब प्रदर्शन के साथ, एक सार्वभौमिक ढांचे के साथ एक प्रबंधित पारिस्थितिकी तंत्र उत्पादकता का राजा है और सभी समर्थित भाषाओं के लिए सभ्य समग्र प्रदर्शन के साथ, उत्पादकता और क्रॉस-भाषा इंटरैक्शन का राजा है। प्रबंधित भाषाओं के युग का चरमोत्कर्ष संभवतः WindowsPhone और VisualStudio 2010 का लॉन्च था (जो इंटरफ़ेस को प्रस्तुत करने के लिए WPF का उपयोग करता था, हालांकि WPF ने मूल कोड के एक सभ्य राशि के शीर्ष पर काम किया था)। उस समय अनुप्रयोगों को विकसित करने के लिए प्रबंधित भाषाओं का एकमात्र अनुमत तरीका था। यह सबसे अच्छी बात नहीं थी जो हो सकती थी। अनसुलझे नेट प्रदर्शन समस्याओं की लंबी सूची को देखते हुए, "देशी डेवलपर्स" को वापस हड़ताल करने के लिए प्रोत्साहित करने के लिए काफी समय था, और उनके पास ऐसा करने का हर अधिकार था।

यह पता चला कि इसका अर्थ एक अर्थ में है। .NET को त्याग देना। मुझे Microsoft की आंतरिक रसोई के बारे में अधिक जानकारी नहीं है, लेकिन लगातार रिपोर्ट्स को देखते हुए, विभागों के बीच एक मजबूत टकराव है। .NET के लिए बेहतर या बदतर, हाल के वर्षों में ऐसा लगता है कि Microsoft कम चल रहा है (उदाहरण के लिए, JIT / NGEN में व्यावहारिक रूप से कोई महत्वपूर्ण सुधार नहीं है, प्रदर्शन सुधार के लिए कई अनसुलझे अनुरोध, जिसमें SIMD जैसी चीजें शामिल हैं, जो डेवलपर्स के लिए इंतजार कर रहे हैं पहले से ही बहुत लंबा समय)। और मुझे ऐसा लगता है कि ये सभी बदलाव तभी संभव हैं जब .NET एक वैश्विक रणनीति है और सभी विभागों के मजबूत समर्थन और भागीदारी के साथ है।

उसी समय, Google ने अपनी NativeClient तकनीक को बढ़ावा देना शुरू किया, जो आपको ब्राउज़र से सीधे सैंडबॉक्स में देशी कोड चलाने की अनुमति देता है। पिछले साल, "गोइंग नेटिव" प्रवृत्ति के बाद, माइक्रोसॉफ्ट ने घोषणा की कि अगले IE के लिए डिज़ाइन किया गया HTML5 भी मूल होगा! इस प्रकार से।

" रीडर क्यू एंड ए: जब बेहतर होगा जेआईटी प्रबंधित कोड को बचाएगी? " गोइंग नेटिव इंजीलिस्ट्स में से एक हर्ब सटर, जेआईटी के "" गोइंग नेटिव "सोच के दर्शन में कुछ दिलचस्प अंतर्दृष्टि प्रदान करता है (" क्या जेट्स तेज हो सकते हैं? " कई गलत तथ्यों के साथ मिगुएल डे इकाज़ा द्वारा पोस्ट), लेकिन चलो बस कुंजी को देखें: भले ही जेआईटी भविष्य में बेहतर हो जाए, प्रबंधित भाषाओं ने पहले से ही सुरक्षा के पक्ष में प्रदर्शन और सुरक्षा के बीच चयन किया है। इस प्रकार, बड़ी लीगों के लिए एक रास्ता उनके लिए पहले ही आर्डर किया जा चुका है।

और उस क्षण में WinRT दिखाई देता है, जो तेज कोनों को थोड़ा चिकना करता है। .NET दर्शन (मेटाडाटा और कुछ सामान्य प्रकारों, जैसे स्ट्रिंग्स और सरणियों) और अच्छे पुराने COM मॉडल (देशी इंटरलेंजिंग इंटरैक्शन के लिए एक सामान्य भाजक के रूप में) का उपयोग करके, WinRT CLR दुनिया के बाहर भाषा इंटरैक्शन की समस्याओं को हल करने की कोशिश करता है (जिसका अर्थ है कि कोई प्रदर्शन हानि नहीं है C ++) और OS के लिए अधिक आधुनिक API प्रदान करता है। क्या यह जीवन, ब्रह्मांड और उस सभी के मुख्य प्रश्न का उत्तर है? वास्तव में नहीं। WinRT के लिए, उन्होंने प्रौद्योगिकियों के एक स्पष्ट अभिसरण के लिए एक कोर्स चुना, जो संभावित रूप से महान चीजों को जन्म दे सकता है, लेकिन अभी तक सही रास्ता चुनने में कोई निश्चितता नहीं है। लेकिन यह "सही तरीका" क्या हो सकता है?

जा रहे मूलनिवासी 2.0 - सभी के लिए प्रदर्शन

सुरक्षा जांच का प्रदर्शन पर नकारात्मक प्रभाव पड़ सकता है, लेकिन प्रबंधित कोड अपने पूरे जीवन को धीमी JIT पर चलाने के लिए बर्बाद नहीं किया जाता है (उदाहरण के लिए, मोनो iOS / लिनक्स पर LLVM के माध्यम से संकलित C # कोड चला सकता है) और असुरक्षित निर्देशों के साथ बाईटेकोड का विस्तार करना काफी आसान होगा ताकि नियंत्रित प्रदर्शन सुधार प्रदान करें (जैसे सरणी बाउंड चेकिंग को ओवरराइड करना)।

लेकिन सबसे स्पष्ट समस्या अब क्रॉस-भाषा संकलक के लिए एक मजबूत बुनियादी ढांचे की कमी है। IE 10 जावास्क्रिप्ट JIT, .NET JIT और NGEN कंपाइलर, विजुअल C ++ कंपाइलर (और कई अन्य) में उपयोग किए जाने वाले कंपाइलर के साथ शुरू - वे सभी लगभग समान समय लेने वाली और जटिल कार्य के लिए अलग-अलग कोड का उपयोग करते हैं - कुशल मशीन कोड उत्पन्न करते हैं। आपके निपटान में एकल संकलक होना सभी भाषाओं में उच्च-प्रदर्शन कोड उपलब्ध कराने में एक बहुत महत्वपूर्ण कदम है।

Channel9 पर फेलिक्स 9 ने पाया कि Microsoft वास्तव में इस मुद्दे पर काम कर सकता है। यह निश्चित रूप से अच्छी खबर है, लेकिन "सभी के लिए प्रदर्शन" का मुद्दा तस्वीर का केवल एक छोटा सा हिस्सा है। वास्तव में, पहले उल्लेख किया गया "सही तरीका" एक व्यापक एकीकृत वास्तुकला है, न केवल एक बेहतर एलएलवीएम स्टैक, बल्कि विभिन्न क्षेत्रों (सी ++ कंपाइलर, जेआईटी, कचरा संग्रहकर्ता, मेटाडेटा, आदि) प्रणाली में माइक्रोसॉफ्ट के कई वर्षों के अनुभव द्वारा समर्थित है, " जो पूरी तरह से एक्स्टेंसिबल और मॉड्यूलर "सीएलआर" प्रदान करेगा:

• इंटरमीडिएट इंटरमीडिएट भाषा । चिंतनशील, सामान्य डेटा प्रकार (आदिम, स्ट्रिंग्स, सरणियों, आदि) को परिभाषित करते हुए LLVM IR या .NET bytecode के समान। System.Reflection.Emit के समान API उपलब्ध होना चाहिए। वेक्टर किए गए प्रकार (SIMDs) इंट और डबल जैसे मूल होने चाहिए। आईएल कोड केवल सीपीयू तक सीमित नहीं होना चाहिए, बल्कि जीपीयू कंप्यूटिंग (सी ++ के लिए एएमपी एक्सटेंशन के रूप में) को भी अनुमति देना चाहिए। इस आईएल का उपयोग करके एचएलएसएल बायोटेक का प्रतिनिधित्व करना संभव होना चाहिए, एकल संकलक बुनियादी ढांचे का लाभ उठाएं (नीचे देखें)। टाइपलेस आईएल भी उपलब्ध होना चाहिए ताकि इसे गतिशील प्रोग्रामिंग भाषाओं को पोर्ट करना आसान हो सके।
• डायनामिकली लिंक्ड लाइब्रेरी और एक्जीक्यूटिव, जैसे .NET असेंबली जो मेटाडेटा प्रदान करते हैं, आईएल कोड जो प्रतिबिंब का समर्थन करता है। डिजाइन के समय में, कोड को असेंबली (आईएल कोड) के साथ संवाद करना चाहिए, और विरासत सी / सी ++ हेडर फ़ाइलों के साथ नहीं।
• IL से मशीन कोड का एक कंपाइलर जिसे JIT, डेस्कटॉप एप्लिकेशन या क्लाउड कंपाइलर या इस सब के संयोजन में एकीकृत किया जा सकता है। इस संकलक को वैश्वीकरण प्रदान करना चाहिए जितना कि लक्ष्य मंच का समर्थन करता है। सिस्टम आर्किटेक्चर के बारे में जानकारी का उपयोग करके इंस्टॉलेशन या तैनाती के दौरान IL कोड को मशीन कोड में संकलित किया जाना चाहिए (विकास के दौरान, यह IL के संकलन के तुरंत बाद किया जा सकता है)। संकलन कदम एपीआई के माध्यम से सुलभ होना चाहिए और जहां भी संभव हो विस्तार बिंदु प्रदान करना चाहिए (आईएल तक पहुंच प्रदान करना, आईएल को अनुकूलित करना, या आईएल से मशीन कोड में देशी परिवर्तनों को एम्बेड करना)। अनुकूलन सेटिंग्स को तेज संकलन (जैसे JIT) से लेकर आक्रामक अनुकूलन (अधिक उत्पादक एक के लिए JIT में पूर्व-संकलित अनुप्रयोग या हॉट-स्वैपिंग कोड) तक होना चाहिए। एक अनुप्रयोग प्रोफ़ाइल का उपयोग स्वचालित रूप से स्थानीयकृत अनुकूलन को ठीक करने के लिए भी किया जा सकता है। यह कंपाइलर उन्नत JIT उपयोग परिदृश्यों का समर्थन करना चाहिए, जैसे डायनेमिक कोड विश्लेषण, ऑन स्टैक रिप्लेसमेंट (OSR, जो वर्तमान समय में अधिक इष्टतम कोड के साथ जटिल गणना के लिए कोड को बदलने की अनुमति देता है), वर्तमान .NET JIT कंपाइलर के विपरीत, जो विधि को संकलित करता है। इसके पहले लॉन्च का समय। इस प्रकार के अनुकूलन गतिशील परिदृश्यों में बहुत महत्वपूर्ण होते हैं जब संकलन के बाद प्रकार का अनुमान होता है (जैसा कि जावास्क्रिप्ट के मामले में)।
• मेमोरी आवंटन के लिए एक एक्स्टेंसिबल घटक, समानांतर मेमोरी आवंटन की अनुमति देता है। कचरा कलेक्टर संभावित कार्यान्वयनों में से एक होगा । अधिकांश एप्लिकेशन इसका उपयोग अधिकांश ऑब्जेक्ट के लिए करेंगे, जबकि अधिकांश प्रदर्शन-महत्वपूर्ण ऑब्जेक्ट अन्य मेमोरी आवंटन रणनीतियों (जैसे COM / WinRT में उपयोग की जाने वाली लिंक की गिनती) का उपयोग करेंगे। एक अनुप्रयोग में कई मेमोरी आवंटन रणनीतियों के उपयोग पर कोई प्रतिबंध नहीं होना चाहिए (यह ठीक वैसा ही है। .NET में तब होता है जब एक एप्लिकेशन को CLR के बाहर ऑब्जेक्ट बनाने के लिए मूल फ़ंक्शन कॉल का उपयोग करना पड़ता है)।

यह विचार सीएलआर स्टैक के बहुत करीब है, लेकिन यह जेआईटी कंपाइलर के शीर्ष पर चलने के लिए अनुप्रयोगों को बाध्य नहीं करता है (हाँ, .NET में NGEN है, लेकिन इसे लोडिंग को गति देने के लिए डिज़ाइन किया गया था, समग्र कार्य में तेजी लाने के लिए नहीं, इसके अलावा यह एक ब्लैक बॉक्स है और यह केवल असेंबली के साथ काम करता है) जीएसी में स्थापित) और मेमोरी को आवंटित करने के लिए मिश्रित रणनीतियों की अनुमति देता है: कचरा कलेक्टर का उपयोग करना और इसके बिना।

इस तरह की प्रणाली में, सादगी और इसके विपरीत प्रदर्शन के लिए बलिदान के बिना इंटरलेन्जेज इंटरैक्शन सरल होगा। आदर्श रूप से, ओएस खुद को एक समान वास्तुकला के आधार पर बनाया जाना चाहिए। शायद यह विचार रेडहॉक (यह संकलक के लिए) या मिडोरी (ओएस के लिए) जैसी परियोजनाओं का आधार है। इस तरह के एक एकीकृत प्रणाली में, शायद केवल ड्राइवरों को हार्डवेयर तक सीधे पहुंच की आवश्यकता होगी।

फेलिक्स 9 ने यह भी खुलासा किया कि एमडीआईएल (.NET बाइटकोड) की तुलना में एक मध्यवर्ती बायोटेक, निम्न स्तर, जिसे एमडीआईएल कहा जाता है, पहले से ही इस्तेमाल किया जा सकता है और यह सिर्फ पहले से वर्णित मध्यवर्ती बायोटेक हो सकता है। यद्यपि, यदि आप इसी पेटेंट " INTERMEDIATE LANGUAGE SUPPORT FOR CHANGE RESILIENCE " को देखते हैं, तो विनिर्देश में आप x86 निर्देश पा सकते हैं जो वास्तुकला-स्वतंत्र बायोटेक की परिभाषा में बिल्कुल फिट नहीं है। शायद वे एमएसआईएल को अपरिवर्तित छोड़ देंगे और एमडीआईएल का उपयोग निम्न स्तर पर करेंगे। हम जल्द ही इसका पता लगा लेंगे।

तो, WinRT इस दृष्टिकोण से क्या समस्याएं हल करता है? मेटाडाटा, एपीआई का एक छोटा सा सैंडबॉक्स और इसकी शैशवावस्था में इंटरला interactionजग बातचीत (हालांकि सामान्य डेटा प्रकार और मेटाडेटा हैं)। जैसा कि आप देख सकते हैं, बहुत कुछ नहीं, एक तरह का COM ++। यह भी स्पष्ट है कि WinRT उन्नत एपीआई प्रदान नहीं करता है जब हम इसके एपीआई का उपयोग करते हैं । उदाहरण के लिए, हमें एम्बेडेड विधियों के साथ संरचना करने की अनुमति नहीं है। WinRT में प्रत्येक विधि कॉल एक आभासी कॉल है जो वर्चुअल विधियों की तालिका के माध्यम से जाएगी (और कुछ मामलों में, कई वर्चुअल कॉल की आवश्यकता होती है, उदाहरण के लिए, स्थिर विधि का उपयोग किया जाता है)। सरलतम पढ़ने-लिखने के गुणों के लिए वर्चुअल कॉल की आवश्यकता होती है। यह स्पष्ट रूप से अक्षम है। जाहिरा तौर पर WinRT केवल उच्च-स्तरीय API पर केंद्रित होता है, ऐसे परिदृश्यों की अनुमति नहीं देता जिनमें हम जहां भी संभव हो, वर्चुअल कॉल और गैर-एम्बेडेड कोड की परत को दरकिनार करते हुए उच्च प्रदर्शन कोड का उपयोग करना चाहते हैं। परिणामस्वरूप, हमारे पास एक विस्तारित COM मॉडल है - यह बिल्कुल वैसा नहीं है जैसा कि "भविष्य का निर्माण" कहा जा सकता है।

C # 5.0 के लिए उत्पादकता और प्रदर्शन

सी # जैसी भाषा इस तरह के मॉड्यूलर सीएलआर सिस्टम के लिए एक आदर्श उम्मीदवार होगी, और आसानी से मौजूदा इंटरमीडिएट के लिए पोर्टेटोड में पोर्ट की जा सकती है। लेकिन ऐसी प्रणाली को प्रभावी ढंग से उपयोग करने के लिए, C # को कई पहलुओं में सुधारना होगा:

• अधिक असुरक्षित निर्माण , जब हम "प्रबंधित" व्यवहार को बंद कर सकते हैं जैसे सरणियों की सीमाओं की जांच करना (जैसे "सुपर असुरक्षित मोड", जब हम सरणी तत्वों तक पहुंचने के लिए सीपीयू में कैश निर्देशों का उपयोग कर सकते हैं, तो इस तरह की "उन्नत" चीजें अब असंभव हैं) undocumented चाल का उपयोग किए बिना प्रबंधित arrays)।
• एक विन्यास योग्य नया ऑपरेटर जो विभिन्न मेमोरी आवंटन योजनाओं का समर्थन करता है।
• वेक्टर प्रकार (जैसे एचएलएसएल में फ्लोट 4) को आधार प्रकारों में जोड़ा जाना चाहिए। यह लंबे समय से पूछा गया है (XNA WP में भयानक पैच के साथ "इस समस्या को" हल करने के लिए)।
• देशी कोड के साथ हल्की बातचीत : वर्तमान स्थिति में, बिना किसी पैरामीटर को पारित किए बिना प्रबंधित कोड से संक्रमण काफी महंगा है। गैर-प्रबंधित कोड पर जाना x86 / x64 prolog / epilog निर्देशों के बिना संभव होना चाहिए जो अब .NETIT में उत्पन्न होते हैं।

प्रदर्शन के अलावा, अन्य समान रूप से महत्वपूर्ण क्षेत्र हैं:

• जेनरिक हर जगह हैं - कंस्ट्रक्टर और निहित प्रकार के रूपांतरणों में, अधिक उन्नत निर्माणों (ऑपरेटरों के लिए अनुबंध आदि) के साथ, C ++ टेम्प्लेट के लचीलेपन के करीब, लेकिन अधिक सुरक्षित और कम बरबाद।
• संरचनाओं में विरासत और फाइनलर्स (हल्के कोड को निष्पादित करने की अनुमति देने के लिए जब विधि बोझिल पैटर्न का उपयोग किए बिना कोशिश करता है / अंत में और उपयोग करके)।
• अधिक मेटाप्रोग्रामिंग । स्थिर प्रकार, अशुद्धियों के लिए विस्तार विधियाँ (एक वर्ग के अंदर वर्ग की सामग्री को जोड़ना, गणितीय कार्यों जैसी चीजों के लिए सुविधाजनक), संकलन समय पर वर्गों / प्रकारों / विधियों को संशोधित करना (उदाहरण के लिए, अन्य विधियों या गुणों को जोड़ने के लिए संकलन समय पर विधियाँ कहा जाएगा) कक्षा में, कोड उत्पन्न करने के लिए टी 4 टेम्पलेट्स का उपयोग करने के बजाय रूबी में ईगेंसेल के समान कुछ है)।
• एक साधारण निर्माण का उपयोग करके किसी भाषा वस्तु (वर्ग, संपत्ति, विधि) के संदर्भ को व्यक्त करने के लिए एक अंतर्निहित शाब्दिक या प्रकार : प्रतीक LinkToMyMethod = @ MyClass.MyMethod ; बजाय Linq अभिव्यक्तियों का उपयोग करने के। यह INotifyPropertyChanged जैसी चीजों के लिए कोड को अधिक मजबूत बना देगा या WPF जैसी सभी संपत्ति-आधारित प्रणालियों को सरल बना देगा (जिसमें वर्तमान स्थिति में बहुत सारे डुप्लिकेट कोड हैं)।

मुख्य विचार यह है कि आपको डेवलपर की उत्पादकता बढ़ाने के लिए और बिना संबंधित प्रदर्शन के नुकसान के पूरी तरह से ऐसी एकीकृत प्रणाली की क्षमताओं का उपयोग करने के लिए C ++ से हटाने के लिए C # से कम जोड़ना होगा । कुछ लोग तर्क दे सकते हैं कि C ++ पहले से ही यह सब और अधिक प्रदान करता है, लेकिन यही कारण है कि C ++ बहुत अधिक अव्यवस्थित (वाक्यविन्यास के संदर्भ में) और अधिकांश डेवलपर्स के लिए खतरनाक है।यह पूरी तरह से हर जगह असुरक्षित कोड की अनुमति देता है, जबकि हर एप्लिकेशन में कुछ निश्चित स्थान होते हैं जहां इसकी वास्तव में आवश्यकता होती है (जो कि मेमोरी समस्याओं की ओर जाता है, जिन्हें ठीक करना आसान होता है यदि इन स्थानों को कोड में स्पष्ट रूप से इंगित किया गया था, जैसा कि कुंजी के साथ किया गया है शब्द ASM)। अपने कोड में इन क्षेत्रों पर नज़र रखना बहुत आसान और सुरक्षित है, क्योंकि उन्हें हर जगह है।

आगे क्या?

हमें उम्मीद है कि Microsoft ने सामान्य से विशेष तक का रास्ता चुना है और WinRT की रिलीज़ के साथ शुरू किया है, जो सभी भाषाओं और सरल क्रॉस-भाषा इंटरैक्शन के लिए एक सार्वभौमिक एपीआई प्रदान करता है। और फिर वे अपने ओएस के अगले संस्करणों में इन सभी अधिक उन्नत सुविधाओं को प्रस्तुत करेंगे। लेकिन यह एक आदर्श स्थिति है और यह देखना दिलचस्प होगा कि क्या Microsoft इसे संभाल सकता है। यहां तक ​​कि अगर हमने हाल ही में घोषणा की है कि WP8 में .NET अनुप्रयोगों को क्लाउड में संकलित करने का लाभ होगा, तो हम अभी भी इसके बारे में बहुत कम जानते हैं: यह सिर्फ एक अनुकूलित NGEN है (जो मुझे याद है, प्रदर्शन-उन्मुख नहीं है और एक के समान कोड उत्पन्न करता है। जेआईटी उत्पन्न करता है) या रेडहॉक कंपाइलर अभी तक पेश नहीं किया गया है?

Microsoft संभवतः C ++ कंपाइलर, JIT, कचरा संग्रहकर्ता, और सभी संबंधित R & D परियोजनाओं को विकसित करने के कई वर्षों को देखते हुए खाली में कुछ है ...

संक्षेप में - .NET को मरना चाहिए और अधिक एकीकृत, प्रदर्शन-उन्मुख एक को रास्ता देना चाहिए, एक सामान्य वातावरण जहां प्रबंधित (सुरक्षा और उत्पादकता) और अप्रबंधित (प्रदर्शन) बारीकी से संबंधित हैं। और यह WinRT विकास के अगले दौर का एक संरचनात्मक हिस्सा होना चाहिए।