विचार 2019 पर

सहकर्मियों, सभी को शुभ संध्या!

हम आपको राफ लेविन के सही मायने में प्रोग्रामेटिक लेख का अनुवाद देने की कृपा कर रहे हैं, जिसका रस्ट भाषा के विकास पर टाइटैनिक का काम सम्मान और श्रद्धा प्रकट करता है:



झूठी विनम्रता के बिना और घृणा के बिना, एक निष्पक्ष और उत्साह से सम्मानित लेखक ने इस लेख की शुरुआत में संदर्भ द्वारा प्रकाशित रुस्त समुदाय की अपील का जवाब दिया। हमें उम्मीद है कि यह दिलचस्प और जीवन की पुष्टि करेगा।


हाल ही में, रस्ट कोर टीम ने 2019 में रूस्ट कैसे बढ़ना चाहिए, इस पर राय के साथ लेख लिखने का प्रस्ताव दिया । यहाँ मेरी राय है

जीवन चक्र का पकना

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

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

जंग की भाषा

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

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

कई कारक हैं जो जंग की सफलता को सीमित करते हैं; मुझे नहीं लगता कि इन कमियों में से अधिकांश भाषा में ही निहित हैं।

उपकरण

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

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

लाइब्रेरी इकोसिस्टम

रस्ट के लिए पुस्तकालय बनाने में अब सबसे गर्म काम जोरों पर है। नीचे मैं उन चीजों को सूचीबद्ध करता हूं जो मैं खुद करने की योजना बना रहा हूं।

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

SIMD

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

सबसे महत्वपूर्ण SIMD बग में से एक यह है कि कंपाइलर में बहुत अधिक काम करने की आवश्यकता है, मोटे तौर पर AVX-512 और गैर- x86 SIMD आर्किटेक्चर के साथ बातचीत के लिए। यह भी संभव है कि रैपर पुस्तकालयों को यथासंभव सुविधाजनक बनाने के लिए भाषा के स्तर पर कुछ परिवर्तनों की आवश्यकता होती है; तो, फिलहाल, एम्बेडिंग और cfg(target_feature = ...) खराब तरीके से इंटरैक्ट करते हैं। मेरी राय में, यह शोध की आवश्यकता वाला एक और मुद्दा है। यह समझना दिलचस्प है कि हम भाषा के स्तर पर अतिरिक्त समर्थन के बिना कितनी दूर जा सकते हैं, और वास्तव में क्या सुविधाएँ इसके साथ काम करने की सुविधा को बढ़ाने में मदद करेगी?

ऑडियो

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

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

इस पर फॉलो करने के लिए, हमारे जूलिप चैट में # सिंथेसाइज़र स्ट्रीम देखें । नवंबर में, मैंने इस बारे में एक व्याख्यान दिया, जिसके आधार पर मैं जल्द ही एक पोस्ट लिखने की योजना बना रहा हूं।

जीयूआई

ग्राफिकल यूजर इंटरफेस वर्तमान में रस्ट के सबसे कमजोर बिंदुओं में से एक है। मुझे लगता है कि 2019 में हम रूस्त समुदाय में इस विषय पर बहुत सारे लेख देखेंगे।
व्यक्तिगत रूप से, यह मुझे लगता है कि रोस्तोव जीयूआई को अब "अनुसंधान" चरण के लिए जिम्मेदार ठहराया जाना चाहिए। कई वैकल्पिक तरीकों पर काम किया जा रहा है, और अब तक इस बात पर कोई सहमति नहीं है कि इनमें से कौन सबसे अच्छा है। सिस्टम आर्किटेक्चर में 2D ग्राफिक्स और अन्य यूजर इंटरफेस प्राइमिटिव्स को कितनी सक्रियता से उपयोग किया जाना चाहिए, या क्या हमें इस पूरे स्टैक को अपने दम पर लागू करना चाहिए? वेब पर तैनाती आवश्यक है (wasm का उपयोग करके)? क्या पूरी प्रोग्रामिंग प्रक्रिया को "जंग-मूल" के रूप में माना जाना चाहिए, या क्या यह कुछ परिपक्व जीयूआई में स्थापित सम्मेलनों के अनुकूल होना बेहतर है? क्या नया जीयूआई टूलकिट बनाने के लिए रस्ट समुदाय के पास पर्याप्त संसाधन हैं, और यदि हां, तो क्या यह इसके लायक है?

मैंने अपने सिंथेसाइज़र और गेम के लिए एक GUI बनाने के लिए Druid प्रोजेक्ट शुरू किया, लेकिन यह प्रोजेक्ट एक शोध है। यह मेरी बात को प्रस्तुत करता है, ऊपर दिए गए सभी प्रश्नों के मेरे उत्तर, और, मेरी राय में, यह परियोजना अच्छी तरह से विकसित हो रही है। लेकिन, मैं दोहराता हूं, यह एक शोध परियोजना है, और इस चरण में इसे अन्य परियोजनाओं में पेश करना बहुत ही मूर्खतापूर्ण होगा।

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

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

अंकन

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

मैं जिस भाषा के साथ रहना पसंद करता हूं, उसे अंतिम रूप देने के लिए रस्ट समुदाय में सभी का धन्यवाद।