यदि आप किसी चीज़ का पता लगाना चाहते हैं, तो सबसे सही से सीखें। आज, मेरे सवालों का जवाब भगवान कॉरटिन और संगति से मिलता है, रोमा एलिज़ारोव एलिसारोव । हमने न केवल कोटलिन के बारे में बात की, जैसा कि आप सोच सकते हैं, लेकिन संबंधित विषयों के एक समूह के बारे में भी:

• गोलंग और गोरोइटिन;
• गंभीर परियोजनाओं के लिए जावास्क्रिप्ट और इसकी प्रयोज्यता;
• जावा और प्रोजेक्ट लूम;
• कोटलिन पर ओलिंपियाड प्रोग्रामिंग;
• कैसे सही ढंग से प्रोग्रामिंग सीखने के लिए;
• और अन्य रोमांचक चीजें।

कोटलिन - अच्छा किया!

नमस्कार। सबसे पहले, अपने बारे में कुछ शब्द। क्या आप लंबे समय से कोटलिन कर रहे हैं?

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

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

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

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

यही है, आप मुख्य रूप से पुस्तकालयों में लगे हुए हैं, एक संकलक नहीं हैं, और यह सब उसके लिए है?

नहीं, मैं कंपाइलर इन्सोफ़र के रूप में कर रहा हूँ। मैं लोगों के साथ संवाद करता हूं, और हमारी लाइब्रेरी टीम वह सब कुछ प्रीफ़ूड करती है जो वे कंपाइलर में करते हैं। हम ग्राहक भी हैं, हम कुछ कमियों के आने पर बहुत सारे फीचर-क्वैश्चंस बनाते हैं, और हम जो कुछ नया करते हैं उसकी पहली पंक्ति के परीक्षक होते हैं।

यह पता चला है, यदि आप YouTrack में जाते हैं, तो आपके द्वारा फ़िल्टर किया गया है, तो आप बहुत सारी दिलचस्प चीजें पा सकते हैं।

हां, आप सभी प्रकार के कार्यों का एक गुच्छा पा सकते हैं, क्योंकि मैं लगातार कुछ भर में आता हूं।

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

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

क्या आप ऐसा करने की सलाह देते हैं?

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

मैंने एक सामान्य समस्या देखी - आपके पास किसी प्रकार का वेब सर्वर है, बहुत सारे लोग इस पर दस्तक दे रहे हैं, और यह थ्रेड्स को ब्लॉक करना शुरू कर देता है।

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

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

लेकिन ऐसी चालाक हैक है: जब आप प्रदर्शन पर वापस जाते हैं, तो वे इसे सभी नहीं, बल्कि केवल बहुत ऊपर से कॉपी करते हैं।

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

और गोश कोड के लिए भी?

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

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

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

लेकिन कोटलिन में यह नहीं है?

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

हमारे मॉडल में, हमारे पास कोई पुराना कोड नहीं है, केवल एक नया है, जो शुरू में इस तथ्य के लिए तैयार है कि आज यह एक धागे पर है, कल दूसरे पर है, और यदि, उदाहरण के लिए, यह पता लगाने की जरूरत है कि कौन सा धागा अब है, इसे पता चल जाएगा। हां, आपको थ्रेड लोकल की जरूरत है, लेकिन वह उन्हें पहचान सकता है। हालांकि, उसे इस तथ्य के लिए तैयार रहना चाहिए कि आज थ्रेड लोकल एक हैं, और कल - अन्य। यदि वह चाहता है कि ये स्थान उसके साथ यात्रा करें, तो इसके लिए एक और तंत्र है, एक coroutine प्रसंग जहाँ वह अपनी चीजों को संग्रहीत कर सकता है, जो coroutine के साथ मिलकर धागे से धागे की यात्रा करेगा। यह एक अर्थ में, हमारे लिए जीवन को आसान बनाता है, क्योंकि हम पुराने कोड को बनाए रखने की कोशिश नहीं कर रहे हैं।

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

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

लेकिन कुछ चीजें हैं जो निषिद्ध करना मुश्किल है, उदाहरण के लिए, किसी प्रकार का नेटवर्क IO, फ़ाइल।

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

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

मुझे लगता है कि यह कितना सुरक्षित है। क्या कोई थ्रेड पूल को तोड़ सकता है या किसी और के डेटा को तोड़ सकता है?

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

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

किन सवालों से?

उदाहरण के लिए, एक प्रश्न में दो लोग बच गए: कोटलिन में कच्चे प्रकार क्यों नहीं हैं? कोई जेनरिक नहीं।

क्योंकि आप हमेशा तारांकन लिख सकते हैं।

और क्या यह जावा के साथ संगत होगा?

हां।

यही है, आपके पास कुछ प्रकार की जावा विधि है जिसके लिए जेनेरिक के बिना कुछ की आवश्यकता होती है। उदाहरण के लिए सूची।

यदि जेनेरिक के बिना ऐसी जावा विधि है, तो आप वहां कोई भी सूची पास कर सकते हैं। आप तारांकन के साथ सूची को स्थानांतरित कर सकते हैं, आप एक स्ट्रिंग के साथ कर सकते हैं। कोटलिन आपको किसी भी गेम को जावा विधि में स्थानांतरित करने की अनुमति देगा। raw List, platform type, , , List . raw type, , Java , . Java, , , , , , raw type. , — , . , — . — , , raw types. , migration story.

platform type ?

flexible. nullable-. , String. , String nullable String — . , String — nullable -nullable. Kotlin , , . String, nullable String. , - Java, .

?

, , , , . Flexible , dynamic. Flexible — , Java, String, nullable String, int.

- - , .

, , . . read only mutable. List MutableList. Java List, , Java- , , - List MutableList. , Java. , Java - , . , , . , , , List, , , MutableList, List . List, String, .

- , ? - ?

, . , . It just works. Java . nullability- , , nullable . , . , , , . , , , , - . , -. - JavaFx, - , JavaFx Java, , . , - , . . , , .

, .

बेशक। , . Kotlin Native. : , seamless C- , , - .

, Native ?

, , Kotlin JavaScript, - - . «Write once, run anywhere», , . : , Common Kotlin Portable Kotlin, , . , - - , , . , , - . , .

JVM , Java, JS , JS, Native . , , , , . - JS, . -. - : double, String. JVM- 0 «0.0», JS . . JS , , — ? , . , , JS- . , -. , . - — , , — . , , , , JVM, JS, Native — , , - . .

?

हां। , , .

, …

, . , . Loom . - JVM. , .

, , Java?

, . . — . , . , - . , for ( i in 0..10 ) , for (int i = first . , , . . , .

- ?

, … , . . JVM JS.

Node.js?

! . , JS-. , , JS- . , . , - — , JS-, - — . , . .

« ». , ?

बेशक। , , . JVM , Java, . JVM . legacy, enterprise, . , , . , JVM. , — , . , . , — JVM « ». . API , . , . , . , , . , , .

TechTrain « ?» । . , .

JS , Kotlin Java?

Java . «Kotlin in Action», , Java-. , Java- , , Kotlin-. , «by design». , Java- . . JPoint , Kotlin . , . , 60-70% Java. Java, , - . Java .

- — , , -. as-is. , , . Kotlin , , «», «». , «» — . while — . 100500 . लेकिन क्यों? , Java-. - , « Kotlin», , .

, . . , , . , .

, -, ?

, . . Java- . Android- — , . . , . — .

- , ?

, . , , . , , . — , , . Kotlin . , . - , , , . : , . C++, Java, Python. . Java - , Java, . , , puiblic static void main… -, . Java, , . ?

Kotlin : , , Python, . C++ , C++ . , , . , . , , . Kotlin — . — Python. . . , . , . . — , , , , — . , .

, — ?

, . must have. , — . . , . — . , , , .

?

… , , . . JS- — . — . JS, , . - JS, type checkers, Flow TypeScript. - JS . Python. - DSL, . Django , . , . , , , . . Django, , CRUD-. , - — . -, - , , . . . Kotlin, , Java, . core belief Kotlin, .

, - , Kotlin ?

बेशक! , , - CRUD-. : , , — , . -, — , . , TypeScript Flow — JS.

Kotlin , Kotlin JS TypeScript , . TS Kotlin/JS, , TS , JS-, . Kotlin/JS , . , .

, — double…

, . , , .

- .

.

?

मैं ओलंपियाड्स पकड़ता हूं :-) और मैं खुद भाग लेता हूं, लेकिन शायद ही कभी।

मैं सिर्फ देखता हूं कि ओलंपिक में जावा कभी-कभी मुख्य भाषाओं में से एक के रूप में उपलब्ध है।

अब यह लगभग हमेशा उपलब्ध है। वह लगभग पंद्रह साल पहले दिखाई दी। जावा और सी ++ दो मानक भाषाएं हैं जो सभी समर्थन करती हैं, और फिर प्रतियोगिता के आधार पर भिन्नताएं।

क्या जावा में जीतना कठिन है, क्या कोई छिपी हुई ओवरहेड्स हैं?

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

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

कोटलिन को मानक भाषाओं की सूची में जोड़ने का विचार आपको कैसा लगा?

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

क्या कोटलिन को पहले ही कहीं पढ़ाया गया है?

कहीं बिल्कुल पढ़ाया जाता है। उदाहरण के लिए, सेंट पीटर्सबर्ग पॉलिटेक्निक में। लेकिन हम इस प्रक्रिया के "चरण 0" पर एक बहुत ही प्रारंभिक चरण में हैं।

कोई घातक दोष नहीं हैं?

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

उदाहरण के लिए, बोनस यह है कि जो व्यक्ति इसे छोड़ देगा, वह वास्तविकता के अधिक अनुकूल होगा।

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

क्या हमारे साथ ऐसा नहीं है?

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

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

क्योंकि आप इस तकनीक की शांत विशेषताओं का उपयोग करके बहुत पैसा कमाएंगे।

बिल्कुल नहीं! कोटलिन में, आपको अधिक आनंद मिलने की संभावना है।

कुछ विशिष्ट चीजें हैं जिनका वास्तव में व्यावसायिक मूल्य है - हमने आगे और पीछे के बीच पुन: उपयोग के बारे में बात की ...

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

यह किसी तरह बहुत सुस्त है, अगर भयानक नहीं है।

यह जीवन का सच है, दुर्भाग्य से। चाहे वह कितना ही भयानक क्यों न हो। और ऐसे लोग, निश्चित रूप से परवाह नहीं करते हैं। कोटलिन, कोटलिन नहीं।

जहां तक ​​मैं समझता हूं, जेटब्रेन में बस बहुत सारे लोग काम करते हैं क्योंकि वे काम करना पसंद करते हैं।

इस संबंध में जेटब्रेन एक गैर-प्रतिनिधि नमूना है, निश्चित रूप से। विशेष रूप से चयनित लोग, प्रेरित, जो वास्तव में इस बात को पसंद करते हैं।

हमारा समय धीरे-धीरे समाप्त हो रहा है, इसलिए सवाल यह है कि क्या आप हमारे पाठकों के लिए हैबे पर कुछ कर सकते हैं? कोई बिदाई शब्द, कुछ रहस्योद्घाटन?

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

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

खैर, यह कुछ हद तक अनुचित प्रतियोगिता है - जावा जैसी इन सभी भाषाओं का आविष्कार कई साल पहले किया गया था, और आपके पास अभी है।

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