“शर्माओ मत। कोशिश करो! एकता एलेक्जेंडर म्यूटेल के साथ जीवन, संकलक और संकलक के जीवन पर साक्षात्कार

सिस्टम प्रोग्रामिंग में सफल होने के लिए आपको क्या जानना और समझना होगा, खासकर यदि आप तीसरे दशक से काम कर रहे हैं? C # और प्रदर्शन - क्या यह सब कुछ आपके द्वारा C # में देखे जाने के लायक है? निम्न-स्तरीय संकलक प्रौद्योगिकियों के लिए भविष्य क्या है?

आज हमारे वर्चुअल स्टूडियो में, अलेक्जेंड्रे मुटल सवालों के जवाब देते हैं।

एलेक्जेंडर म्यूटेल यूनिटी टेक्नोलॉजीज में एक लीड सॉफ्टवेयर आर्किटेक्ट है। इसके अलावा, वह एक प्रसिद्ध ओपन सोर्स डेवलपर है जो SharpDX, Markdig, Zio और अन्य परियोजनाओं में योगदान दे रहा है, और 2014 के बाद से - विजुअल स्टूडियो एंड डेवलपमेंट टेक्नोलॉजीज श्रेणी में MVP।

अलेक्जेंडर वास्तविक समय ग्राफिक्स प्रतिपादन, GPGPU, ध्वनि संश्लेषण, कुशल उपयोग और प्रबंधित भाषाओं की वास्तुकला, कोड पीढ़ी और प्रलेखन में निम्न-स्तरीय और उच्च-स्तरीय मुद्दों की एक किस्म पर काम कर रहा है।

हमेशा की तरह, JUG.ru समूह से इवगेनी ट्रिफ़ोनोव ( फिलीनियम ) और ओलेग चिरुखिन ( ऑलीगचिर ) द्वारा साक्षात्कार आयोजित किए जाते हैं।

पोस्ट के अंत में डायलन बीट्टी (एक अन्य प्रसिद्ध दाता) से एक आश्चर्य है - हमें खुद इसकी उम्मीद नहीं थी।

ई।: आपके पास एक लंबा कैरियर है, तीन दशक - शुरुआत के लिए, क्या आप इसके बारे में संक्षेप में बात कर सकते हैं?

यह सब बचपन में शुरू हुआ था - मुझे Amstrad PC 464 मिला। जब मैंने इस कंप्यूटर पर प्रोग्रामिंग शुरू की, तब मैं 11 या 12 साल का था, मुझे ठीक से याद नहीं है। मैंने जल्दी से BASIC प्रोग्रामिंग में महारत हासिल की और खेल के विकास पर किताबें खरीदीं: तब यह बहुत दिलचस्प लग रहा था। मैंने बहुत कम खेल खेले, जहाँ कोड विकसित करना और लिखना अधिक दिलचस्प था। फिर मैंने अम्स्ट्रैड के लिए कोडांतरक कोड लिखना जारी रखा।

16 साल की उम्र में, मुझे एक एमिगा 500 मिला। मैं उन लोगों से मिला जो डेमो लिख रहे थे - यह बिल्कुल भी नहीं था कि यह अब क्या है। अब यह वेबजीएल है, और यह एक पूरी तरह से अलग है। मैंने बहुत सारे डेमो लिखना शुरू किया, जो मैंने हमेशा नहीं दिखाया, लेकिन मुझे सिर्फ असेंबलर में लिखना पसंद था। और यह इतना आसान था।

फिर वह एक तकनीकी कॉलेज गया, जहाँ उसने कंप्यूटर इंजीनियरिंग की पढ़ाई की। गेम और असेंबलर की तुलना में यह पहले से ही पूरी तरह से अलग था। मुझे उन चीजों को सीखना बहुत पसंद था, जिन्हें मैं पहले भी जानता था: ऑपरेटिंग सिस्टम, UNIX, C भाषा के साथ काम करना (इससे पहले मैंने केवल BASIC या असेंबलर का उपयोग किया था क्योंकि मेरे पास C / C ++ कंपाइलर खरीदने के लिए पैसे नहीं थे)।

जब उन्होंने कॉलेज से स्नातक किया, तो उन्होंने मुद्रा बाजार उद्योग में काम करना शुरू किया। यह न्यूयॉर्क में एक फ्रांसीसी कंपनी के लिए एक नौकरी थी। दो साल बाद, मैं लौट आया और बैंक गया। दरअसल, मैं बैंक में काम नहीं करना चाहता था, मैं खेल देव में काम करना चाहता था। लेकिन परिणामस्वरूप, एक नया क्षेत्र अटक गया है, बहुत सी चीजें सीखी जा सकती हैं। इसलिए मैंने वहां 8-9 साल बिताए, मुख्य रूप से जावा और सी ++ के साथ थोड़ा व्यवहार किया। बहुत सारे वितरित सर्वर और SQL डेटाबेस, डेटाबेस की प्रतिलिपि बना रहे हैं ... बिल्कुल नहीं मैं अब क्या कर रहा हूं।

फिर मैंने कुछ रचनात्मक छुट्टी ली और दुनिया भर में एक पर्यटक यात्रा पर गया: मैं अफ्रीका में, दक्षिण अमेरिका में, पूरे एक साल एशिया में रहा। सफर ने मुझे बदल कर रख दिया। जब मैं वापस लौटा, तो मैं अब कंप्यूटर के साथ काम नहीं कर सकता, आईटी क्षेत्र में, मैं बैंक के लिए काम नहीं कर सकता था। मैंने अपनी नौकरी छोड़ दी और बच्चों, बेघरों, विकलांगों, बुजुर्गों के साथ काम करने के लिए सामाजिक कार्यकर्ता पाठ्यक्रमों में 4 साल बिताए। मैंने तीन साल तक इसका अध्ययन किया, और यह बहुत दिलचस्प था, क्योंकि मेरे अधिकांश जीवन ने सटीक विज्ञान के क्षेत्र में काम किया: गणित, परियोजनाएं, सार। और फिर वह अचानक ले गया और बहुत मानवीय क्षेत्र में चला गया। मैंने प्रशिक्षण के बाद भी इस क्षेत्र में काम करने की कोशिश की, लेकिन इस अवधि के दौरान एक मित्र, जिसके साथ मैंने एक बच्चे के रूप में डेमो किया, ने संकेत दिया कि हम फिर से ऐसा कर सकते हैं।

मैंने अपने सभी खाली समय में डेमो का अभ्यास करना शुरू कर दिया, और बहुत जल्दी यह सड़क पर बच्चों के साथ काम करने से अधिक लेने लगा। वह बुरा था। लोगों ने कहा: “हमें खेल देव में काम पाने की कोशिश करने की ज़रूरत है, क्यों नहीं? आप इसे कर सकते हैं। ” लेकिन मुझे लगा कि यह असंभव था, क्योंकि मैंने लंबे समय तक कंप्यूटर के साथ काम नहीं किया था, और मेरे फिर से शुरू होने के साथ आईटी में काम करना मुश्किल था।

मैंने ओपन सोर्स एप्लिकेशन पर काम करना शुरू कर दिया और कुछ ऐसे प्रोजेक्ट जारी किए, जिन्हें कंपनियों ने इस्तेमाल करना शुरू किया। एक बार, इन कंपनियों में से एक ने मुझसे संपर्क किया, उन्होंने एक नवीनतम परियोजना का इस्तेमाल किया जिसका नाम था SharpDX। मैं अपने परिवार के साथ जापान गया - क्योंकि मेरे पहले से ही दो बच्चे हैं। हम जापान में 5 साल रहे। इस समय, मैं C # में स्क्रैच से गेम इंजन बनाने पर काम कर रहा था।

लगभग दो साल पहले, मैं फ्रांस लौट आया और यूनिटी में काम करना शुरू कर दिया। इससे पहले कि मैंने जो कुछ भी किया था, उसके साथ हस्तक्षेप किया, लेकिन उन्होंने एक बहुत ही जटिल और दिलचस्प काम पर काम करने की पेशकश की, एक वास्तविक परीक्षण: एक मूल संकलक बनाने के लिए जो आईएल .NET कोड से मूल कोड उत्पन्न करता है। यह वही था जो मैं हमेशा करना चाहता था, लेकिन नहीं कर सका, क्योंकि मुझे इसके लिए भुगतान नहीं किया गया था। और फिर एक मौका था, एक शानदार मौका। मैंने 2 साल तक इस प्रोजेक्ट पर काम किया।

हां, लगता है कहानी बहुत कम नहीं है।

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

मैं इस सुनहरे मतलब का पालन करता हूं। (हंसते हुए) मेरा मानना ​​है कि बहुत से, यदि हम ज्यादातर अनुप्रयोगों को विकसित नहीं करते हैं तो वे शुरुआत से ही प्रदर्शन आवश्यकताओं के अनुकूल हो जाते हैं, जिसके परिणामस्वरूप सर्वोत्तम संभव गुणवत्ता होती है।

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

वही सभी सॉफ्टवेयर के बारे में कहा जा सकता है जो हम विकसित करते हैं। और क्या आश्चर्य की बात है: हमेशा मूल कोड के साथ काम करने की प्रवृत्ति रही है, कुछ बिंदु पर भी विंडोज में उन्होंने C ++ पर लौटने का फैसला किया, उन्होंने कहा: "C ++ एक समाधान है। .NET बहुत धीमा है, फिर कचरा कलेक्टर और ब्ला ब्ला ब्ला ... "। और फिर, देशी भाषाएँ प्रासंगिक हो गईं।

उसी समय, क्रोम में V8 ने JIT की बदौलत जावास्क्रिप्ट को वापस उपयोग में लाया। JS एक स्क्रिप्टिंग भाषा है, सुपरफास्ट नहीं, लेकिन कभी-कभी यह C ++ की तुलना में दोगुनी तेजी से काम करती है। विजुअल स्टूडियो कोड में कोड लिखने जैसी चीजों के लिए उसका उपयोग करना हमारे लिए पर्याप्त था और अभी इसका उपयोग करना है। लेकिन अगर आप बारीकी से देखते हैं, तो यह सब कुछ है क्योंकि प्रदर्शन की आवश्यकताओं को शुरू से ही वहां रखा गया था। VSCode में, भले ही सामान्य रूप से जावास्क्रिप्ट और स्क्रिप्ट कोड का एक बहुत कुछ है, बाकी सब - V8, रेंडरिंग स्टैक, JIT - यह सब अधिकतम प्रदर्शन के लिए डिज़ाइन की गई भाषा में लिखा गया है, जो कि C ++ में है। सब कुछ एक और भाषा में लिखा जा सकता है, जरूरी नहीं कि C ++, लेकिन तथ्य यह है कि यह सब सॉफ्टवेयर शुरू से ही प्रदर्शन को ध्यान में रखते हुए विकसित किया गया था।

तो हाँ, हम कम कुशल और उत्पादक भाषाओं का उपयोग कर सकते हैं, लेकिन केवल इसलिए कि सभी अंतर्निहित तकनीकों को एक शानदार उपयोगकर्ता अनुभव प्राप्त करने के उद्देश्य से विकसित किया गया है । उदाहरण के लिए, विजुअल स्टूडियो कोड अद्भुत सॉफ्टवेयर है जो डेवलपर्स के लिए बहुत अच्छा काम करता है और उनकी समस्याओं को हल करता है। बहुत से लोग कहते हैं: "हालांकि हम अधिक देशी कोड संपादकों का उपयोग करना पसंद करते हैं, अभी हम विजुअल स्टूडियो कोड पर स्विच कर रहे हैं" - क्योंकि वे काफी प्रभावी मानते हैं। प्रदर्शन हर जगह है, लेकिन कभी-कभी हम इसे नहीं देखते हैं क्योंकि यह पहले से ही हमारे द्वारा उपयोग की जाने वाली हर चीज में अंतर्निहित है।

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

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

ई।: आंशिक रूप से एक दार्शनिक प्रश्न है। आपको लगता है कि स्लैक तकनीकी समाधान के लिए सबसे अच्छी जगह नहीं है, लेकिन आपकी साइट पर आप पुराने स्कूल आरएसएस की सदस्यता लेने की पेशकश करते हैं। क्या आपको लगता है कि इंस्टेंट मैसेजिंग का नया युग डेवलपर्स को कम उत्पादक बना रहा है?

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

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

ई।: धन्यवाद, ओलेग के सवालों के लिए समय!

ए।: मेरा कैरियर कुछ हद तक आपके जैसा है: मैंने एक बैंक में काम किया, अब एक पूरी तरह से अलग क्षेत्र में - सम्मेलनों के आयोजन में, और उसी समय मैं यह पता लगाने की कोशिश कर रहा हूं कि कंपाइलर कैसे बनाए जाएं। आप उन लोगों को क्या सलाह दे सकते हैं जो सरल उद्यम वेब-डेवलपर्स से सिस्टम प्रोग्रामिंग पर स्विच करने की कोशिश कर रहे हैं, क्या ऐसे संक्रमण के लिए कोई सुझाव हैं? मुझे यकीन है कि यहाँ हमारे लिए पर्याप्त नहीं हैं, पर्याप्त तक हैं।

निश्चित नहीं है कि क्या इस तरह के संक्रमण के लिए एक तैयार रास्ता है। यदि आप ऐसी तकनीकों में रुचि रखते हैं, तो आप कुछ सामान्य होमवर्क करते हैं। घर पर, आप पार्सर और कंपाइलर्स से जुड़ी चीजें लिखते हैं। मशीन कोड की बहुत पीढ़ी तक, शुरुआत से अंत तक पूरे संकलक को लिखना आवश्यक नहीं है। आप कंपाइलर इन्फ्रास्ट्रक्चर लिखने में रुचि रखते हैं। यह मैं हाल के वर्षों में एकता में काम कर रहा हूं। यदि आप निम्न-स्तरीय चीजों के बारे में भावुक हैं, तो यह उन जगहों में से एक है जहां आप समझ सकते हैं कि यह वास्तविकता में कैसे काम करता है। काम में सुधार कैसे करें, जहां यह प्रदर्शन में सुधार के लायक है, और जहां यह अभी तक नहीं किया गया है। यदि आप प्रदर्शन के बारे में चिंतित हैं, तो यह जानना बहुत महत्वपूर्ण है कि आवेदन आखिर में क्या चलेगा।

प्रदर्शन मेरा विषय है, और यह सब मेरे लिए एक महान अवसर बन गया है। मैं समस्या के समाधान को उसके मूल, यानी संकलक स्तर पर पहुंचाना चाहूंगा। यह यहां है कि हम उन स्थानों पर उत्पादकता का दस गुना बढ़ा सकते हैं जहां यह हमारे उपयोगकर्ताओं के लिए आवश्यक है। यदि हम गेम, एप्लिकेशन, मूवी या ऐसा कुछ चलाते हैं, तो ऐसे परिणामों को प्राप्त करना कभी-कभी अपेक्षाकृत आसान हो सकता है।

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

A: आपने उल्लेख किया है कि आपने पिछले 10 वर्षों से C # में प्रोग्राम किया है। तो C # में क्या अच्छा है? उदाहरण के लिए C ++ क्यों नहीं? C ++ अधिक व्यवस्थित भाषा लगती है।

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

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

मुझे सी ++ कंपाइलर और लिंकर की त्रुटियों से नफरत है, मुझे विभिन्न प्लेटफार्मों के साथ काम करने की आवश्यकता से नफरत है, यह सब बहुत मुश्किल है। आप MSVC पर संकलन शुरू करते हैं, फिर आपको क्लैंग पर स्विच करना चाहिए, फिर जीसीसी को। लिनक्स पर, मैक पर, विंडोज पर, एंड्रॉइड पर, आईओएस पर और इसी तरह आगे। C ++ के साथ काम करना एक बुरा सपना है!

मुझे एडिटर, .h फाइल्स और सीपीपी फाइलों के बीच के अलगाव से नफरत है। लोग भाषा में पूरी तरह से भ्रमित हैं और मैक्रोज़ पर कार्यक्रम करना शुरू करते हैं। , C++ . , - .

: , , C#. , , C++, . Unity — , burst compiler, C#, , , C++ — C#. . unsafe, , . . - , , C++. , , .NET .

.: , , .NET Core, C-. , , - ( ). , C#?

हाँ! , JIT Microsoft, . -, . , , , , . . , - . Garbage Collector JIT. - .NET, JIT GC, C#. , C++ , . , . .

, . , C/C++ , - . , . - , IDE , , — . C#, . , , . . , , , CoreRT C# C++. .

, .NET GC C#. . , , .NET GC, -. GC, , - GC. Java- Jikes RVM — Java. , Golang C, Golang. Golang-, , . , , , . , . LLVM, .NET JIT.

, , .

.: , . — . , AST- . Golang , . , ? ?

, , ! , . : . : -, .

: , , , , . , : « ! !». . , .

LLVM, — , . , , , , , . . , , . , . , , , , ? , , , . , - : «, , , - » — , , , .

, . , , , , , , - . , : , , . , , . , , . , . , — .

— . -. , -, API, . . , SharpDX . . , , , . DirectX C++ API, C++. , . , - , . : , . , SharpDX. , PR, . pull request ( ). - . - , SharpDX - . : « ?» ( , ) , . 90- — . , , .

, , , , : , , .

.: — , ? . , , ?

, — , SIMD. , , SIMD , . ( LLVM, , ). , , . , , , . - , . , . . - Intel LLVM. , , LLVM. , , . LLVM — , , , .NET. SIMD, CPU — . , , .NET — SIMD- . , , .

: « ». . . LLVM : -, , . , , Roslyn C#, . , , . , , , . SIMD — . GPU, CPU, — . 6, 8, 16, 42 . - , , .

.: Markdown Markdig, ? , Markdown? , ?

, Markdown — , . , , Word - . . ? , , . . , RFC — , , , . , , . , ASCII-art. Word, PDF . Word. - — . , . Markdown, , - — , HTML. , . HTML, Markdown . , Github, Markdown- . . — . , Microsoft Markdown, GitHub, PR — , .

Markdown, CommonMark, , Markdown. , CommonMark — . , , . , Github CommonMark . — . . Microsoft CommonMark, Markdig. , Markdig , Markdown-, . , , , CommonMark, Markdig. , . Markdig , , , . , Microsoft .

.: , ? ?

, . — , . . , . , , , . , . « , , ». , ? , , , , , - . , Google « X» « ». , — . , , , . , , - — , . « , - ?»

, , . . , , . , - . , , , . — , , ? , ? , .

, . . ? ? , , . , … - , . . , , , .

. . ! , . — . , — - . , , , . , , , . , . , . . , - : « !». -, , , . , . .

यह स्व-विकासशील होने के बारे में एक कहानी है, जितने संभव हो उतने प्रश्न पूछें, जिन लोगों से आप मिलते हैं, उन घटनाओं के बारे में खुला रहने की कोशिश करें, जिनके बारे में आप उपयोग कर सकते हैं, और खुद से अधिक कुछ में भाग ले सकते हैं।

---

अगले शुक्रवार, एलेक्जेंड्रा डॉटनेट 2018 मॉस्को में एलएलवीएम का उपयोग करके .NET आईएल को अत्यधिक अनुकूलित देशी कोड में परिवर्तित करने के लिए एक प्रस्तुति बना देगा। सम्मेलन 22-23 नवंबर को मास्को में आयोजित किया जाएगा और ऐसा लगता है, यह सभी का सबसे बड़ा डॉटनेट होगा। हम आपको बताएंगे कि सम्मेलन से और क्या उम्मीद की जा सकती है, लेकिन हमारे लिए उनके दूसरे वक्ता, डायलन बीट्टी द्वारा बेहतर किया गया था - उन्होंने पूरा गाना रिकॉर्ड किया: