कोर्डा: कोटलिन

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

कोटलिन क्यों?

इस समाधान को दो भागों में विभाजित किया जा सकता है:

1. किस प्लेटफॉर्म का उपयोग करना है? JVM, .NET, नोड, पायथन / रूबी, गो, हास्केल या कुछ संकलित (मशीन कोड में)?
2. यदि आप JVM चुनते हैं तो किस भाषा का उपयोग करना है? जावा? यदि नहीं, तो क्यों? और यदि नहीं, तो और क्या: स्केला, सीलोन, क्लोजर, कोटलिन, पायथन, रूबी, जावास्क्रिप्ट या हास्केल (क्योंकि वे सभी जेवीएम के लिए एक कार्यान्वयन हैं)।

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

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

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

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

डायनेमिक टाइपिंग पर विचार नहीं किया गया है - स्टैटिक टाइपिंग द्वारा प्रदान किए गए शुद्धता, विकास उपकरण और प्रदर्शन के लाभों की उपेक्षा की जा सकती है।

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

नतीजतन, इन आवश्यकताओं ने हमें कोटलिन, स्काला और सीलोन के साथ छोड़ दिया। ये भाषाएं काफी समान और काफी रोचक हैं। हमने निम्नलिखित कारणों से कोटलिन को चुना:

• जावा के साथ लगभग सहज एकीकरण
  
  • विशेष रूप से, कोटलिन कार्यक्रम मानक JDK संग्रह के संवर्धित (संकलक-संवर्धित) संस्करण का उपयोग करते हैं, जो इस प्रकार यह सुनिश्चित करता है कि अन्य संग्रह पुस्तकालयों के उपयोग के कारण एकीकरण की समस्याएं नहीं हैं। हम हर जगह जावा पुस्तकालयों से और उनके लिए संग्रह प्रसारित और प्राप्त करते हैं, इसलिए यह महत्वपूर्ण है कि इससे समस्याएं पैदा न हों।
  • कोटलिन वर्गों से, हमें एक सादे-दिखने वाला जावा एपीआई get जिसमें / set / प्रकार के अनुसार विधियां हैं। इसके लिए कोई विशेष एनोटेशन या अन्य कार्यों की आवश्यकता नहीं होती है। इस कारण से कि कॉर्डा जावा डेवलपर्स द्वारा पारदर्शी उपयोग के लिए डिज़ाइन की गई एक एपीआई प्रदान करता है, यह एक बड़ा फायदा है: साधारण कोड से, एक एपीआई प्राप्त होता है जिसे केवल कुछ कैविएट्स के साथ जावा एपीआई से अलग नहीं किया जा सकता है (उदाहरण के लिए, जावा से चेक किए गए अपवादों के स्पष्ट अवरोधन के लिए स्पष्ट रूप से आवश्यक है विधि एनोटेशन)
• संकलक द्वारा map / filter / fold / groupBy जैसे छोटे कार्यों को groupBy (उम्मीद है कि JVM इसे स्वयं करेगा) के बजाय। दुर्भाग्य से, JIT JVM संकलक, हालांकि उत्कृष्ट समग्र, सभी मामलों में उच्च-क्रम कार्यों के प्रचुर उपयोग के ओवरहेड को समाप्त नहीं करता है। कोटलिन का उपयोग आपको लैम्ब्डा कार्यों के भीतर से कार्यक्रम के निष्पादन को नियंत्रित करने की अनुमति देने के अलावा इसकी भरपाई करता है (नोट: उदाहरण के लिए, गैर-स्थानीय रिटर्न)। यह अल्पज्ञात, लेकिन एक ही समय में उपयोगी सुविधाओं में से एक है। क्योंकि हर जगह हम ऐसी कार्यात्मक शैली में कोड लिखते हैं, फिर अगर इसे मशीन कोड में खराब तरीके से अनुवादित किया गया, तो हम अपने लिए प्रदर्शन की समस्याएं पैदा कर सकते हैं।
• इस तथ्य के कारण कि कोडलिन पर कोड का काफी समान जावा कोड में अनुवाद किया गया है, लगभग सभी मौजूदा जावा-उन्मुख उपकरण बॉक्स से बाहर काम करते हैं । यह हमेशा अन्य भाषाओं के मामले में सच नहीं है। उदाहरण के लिए, क्वासर को स्काला कोड को लागू करने में कठिनाई होती है क्योंकि इसे विधि एनोटेशन की आवश्यकता होती है, और स्काला लैम्बडा को उन तरीकों में अनुवाद करता है जिन्हें एनोटेट नहीं किया जा सकता है। कोटलिन लैम्ब्डा आमतौर पर एम्बेडेड होते हैं (ऊपर देखें), या अन्यथा एनोटेट किया जा सकता है।
• उत्कृष्ट प्रलेखन और एक छोटा मानक पुस्तकालय इसे सीखने में बहुत तेज़ बनाता है। हमने अपनी रिक्तियों में कोटलिन पर अनुभव की आवश्यकता का संकेत नहीं दिया, और हमने 1-3 साल देने के बिना लोगों को उनके ज्ञान के बिना काम पर रखा, जिसके बाद टीम का एक नया सदस्य मुहावरेदार कोड लिखने में सक्षम था।
• हमारे द्वारा साक्षात्कार करने वाले उम्मीदवारों के चयन के आधार पर, इंटेलीज सबसे लोकप्रिय आईडीई है (उनके पास उपकरण का एक मुफ्त विकल्प था)। जावा के बाद की भाषाओं में, इंटेलीजे कोटलिन का सबसे अच्छा समर्थन करता है।
• मुझे पहले से ही उनके साथ एक संतोषजनक अनुभव था, और इसलिए, मुझे यकीन था कि उनके नए सहयोगी भी उन्हें पसंद करेंगे।

यदि यह कोटलिन के लिए नहीं था, तो हमने शायद स्काला को चुना: कोटलिन काफी हद तक इससे प्रेरित है और दोनों ही अच्छी भाषाएं हैं।

कोटलिन के साथ हमारा साल

ऐसा क्या है - एक कॉर्पोरेट अनुप्रयोग के संदर्भ में एक नई भाषा के साथ काम करने के लिए एक वर्ष?

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

निम्नलिखित कुछ समस्याएं हैं जो अक्सर एक पोस्ट-जावा / सी # उद्यम विकास वातावरण में होती हैं जो हम खुद का सामना करते हैं:

• यह किसने लिखा है इसके आधार पर कोड अलग दिखता है। सामान्य तौर पर, इतनी बड़ी समस्या नहीं। गो के विपरीत, जिसे डिजाइन की एक निश्चित शैली की आवश्यकता होती है, विभिन्न लेखकों के कोटलिन कोड अलग दिख सकते हैं। लेकिन इंटेलीज में एक प्रारूपण उपकरण है जो एकीकृत कोड आधार शैली प्रदान करता है। यह जावा की तुलना में अधिक सीमित है, लेकिन यह पर्याप्त है। विशेष रूप से स्काला कोड के साथ एक अधिक सूक्ष्म समस्या, जावा-ओओपी और हास्केल-एफआई कोडिंग शैली का विरोध है। स्काला कोड जैसे कि स्केलज़ जैसे पुस्तकालयों का उपयोग करने वाले डेवलपर्स के लिए पढ़ना मुश्किल हो सकता है जो बेहतर जावा को देखने की उम्मीद करते हैं। इस बहस में, बेहतर जावा के पक्ष में कोटलिन दृढ़ता से है। और, हालांकि कार्यात्मक प्रोग्रामिंग, एक निश्चित तरीके से, संभवतः कोटलिन पर, समुदाय (अभी के लिए कम से कम) शिविरों में विभाजित नहीं हुआ है। हमारे पास ऐसे मामले थे जब कोड लिखा गया था जैसे कि यह हास्केल था, लेकिन इसे कोडरेव्यू पर काम किया गया था।
• लाइब्रेरी। कॉर्डा में हम 50 से अधिक ओपन सोर्स लाइब्रेरी का उपयोग करते हैं और किसी के साथ कोई समस्या नहीं थी। हमने कभी एडाप्टरों के रैपर या परत नहीं लिखे। जैसा कि कोटलिन, मावेन या ग्रैडल पर परियोजनाओं में सिस्टम का उपयोग किया जाता है - आमतौर पर इन उपकरणों के लिए कोई आधिकारिक कोटलिन-विशिष्ट प्रतिस्थापन नहीं है (हालांकि ग्रैडल ने कोटलिन समर्थन को एक नई स्क्रिप्टिंग भाषा के रूप में पेश किया है!)।
• डीएसएल और एसक्यूएल। C # में LINQ है, जावा में JOOQ है, और Kotlin एक्सपोज़्ड है । यह उन क्षेत्रों में से एक है जहां कोटलिन अपने प्रतिद्वंद्वियों की तुलना में थोड़ा कमजोर है - एक्सप्लॉइट डीएसएल के निर्माण के लिए कोटलिन की क्षमताओं का उपयोग करने का एक उत्कृष्ट उदाहरण है, लेकिन पुस्तकालय में एक अस्थिर एपीआई है और एक माध्यमिक परियोजना है। JOOQ, बेशक, कोटलिन के साथ इस्तेमाल किया जा सकता है, और पीछे मुड़कर देखें, तो यह पसंदीदा विकल्प लगता है।
• आईडीई / टूलकिट। IntelliJ के लिए कोटलिन प्लगइन, बेशक, JetBrains द्वारा लिखा गया है और, कुल मिलाकर, बहुत अच्छा है। हालांकि, जावा समर्थन की तुलना में यह कम परिष्कृत है। नए संपादक फीचर्स, जैसे कि एक पैरामीटर संकेत , को मैन्युअल रूप से कोटलिन में पोर्ट किया जाना चाहिए, और समर्थन स्वयं, जैसे कि, आमतौर पर बहुत पुराने जावा प्लग-इन से पीछे रहता है। हमने यह भी देखा कि आईडीई प्लगइन अक्सर आंतरिक त्रुटियों को सूचित करता है, हालांकि वर्ष के दौरान आईडीई अपवादों की आवृत्ति में काफी कमी आई है (और ऐसा लगता है कि वे कुछ भी प्रभावित नहीं करते हैं)। अन्य उपकरणों का उपयोग करने से भी समस्या नहीं होती है, क्योंकि जावा के लिए जो लिखा जाता है वह आमतौर पर बॉक्स से बाहर काम करता है । एक अपवाद उपकरण है जो बाइटकोड के बजाय स्रोत कोड के साथ काम करता है, और जो, जाहिर है, पुन: उपयोग नहीं किया जा सकता है। इस सब के साथ, कोटलिन कंपाइलर और आईडीई प्लगइन 1.0 के रिलीज के एक साल बाद भी जावा के मामले में उतने डिबग नहीं किए जाते हैं। सबसे अधिक संभावना है कि आप javac में आंतरिक त्रुटियों का सामना नहीं करेंगे, लेकिन, हालांकि बहुत कम ही, हम अभी भी उन्हें कोटलिन में देखते हैं।
• उपयोगकर्ताओं द्वारा मान्यता। कॉर्डा उपयोगकर्ता अक्सर बड़े और रूढ़िवादी वित्तीय संस्थान हैं। ऐसी कंपनियां आम, अच्छी तरह से स्थापित भाषाओं का उपयोग करना पसंद करती हैं। कोटलिन, न तो एक और न ही दूसरे, स्पष्ट रूप से उस समय कुछ आश्चर्यचकित हुए जब हमने शुरुआत की थी। "कोटलिन क्यों?" - यह एक ऐसा प्रश्न है, जो पिछले एक साल से व्यावहारिक रूप से गायब हो गया है, क्योंकि लोगों ने बारीकी से देखा और महसूस किया कि यह उतना जोखिम भरा नहीं है जितना कि आमतौर पर नई प्रोग्रामिंग भाषाओं के साथ होता है। हमने कोड उदाहरण प्रदान करके गोद लेने की सुविधा प्रदान करने की भी कोशिश की, जिसमें प्रदर्शित किया गया कि प्लेटफ़ॉर्म का उपयोग करके बिल्डिंग एप्लिकेशन को कोटलिन ज्ञान की आवश्यकता नहीं है। इसके परिणाम इतने सफल नहीं थे - कॉर्डा के साथ पहली बार काम करने वाले कई डेवलपर्स अभी भी कोटलिन की खोज करके शुरू करते हैं। यह बहुत स्पष्ट नहीं है कि क्या यह इस तथ्य का परिणाम है कि हमने अपर्याप्त रूप से जावा-उन्मुख उपयोग के उदाहरण और दस्तावेज प्रदान किए हैं, या यह एक नया शांत उपकरण सीखने के लिए सिर्फ एक अच्छा बहाना है। हमें प्रमुख निवेश बैंकों के अंदर कोटलिन के बढ़ते गोद लेने से भी मदद मिली है। पिछले एक साल में, हमने कंसोर्टियम के कई सदस्यों से सुना है कि उनकी आंतरिक विकास टीमों ने अपने स्वयं के उत्पादों के लिए कोटलिन को गंभीरता से देखना शुरू कर दिया है: अक्सर उन उपकरणों की उपलब्धता से प्रेरित होता है जो जावा को कोटलिन में परिवर्तित करते हैं, जो मौजूदा कोड बेस में काफी कम दर्दनाक एकीकरण प्रदान करते हैं।
• वाणिज्यिक समर्थन। अल्प-ज्ञात भाषाओं का उपयोग करने का जोखिम यह है कि वे विकास करना बंद कर सकते हैं, या ऐसे लक्ष्य हो सकते हैं जो उत्पाद, उपयोगकर्ता समुदाय (उदाहरण के लिए, अनुसंधान भाषाओं के मामले में, डेवलपर्स का मुख्य लक्ष्य वैज्ञानिक लेख बनाना है) के अनुरूप नहीं हैं। हमें कोटलिन के साथ विश्वास करने का मुख्य कारण यह है कि JetBrains एक स्थिर, लाभदायक कंपनी है जो 15 से अधिक वर्षों से बाजार में है। JetBrains ने जल्दी से मुख्य उत्पादों के कोड में कोटलिन को पेश करके अपने स्वयं के उपकरण का स्वाद लेना शुरू कर दिया। इस प्रकार, समर्थन की समाप्ति का जोखिम कम है। इसके अलावा, JetBrains पहले से ही एक मध्यम आयु वर्ग की कंपनी है, और इसका लक्ष्य बाजार (IDE और डेवलपर उपकरण) नया या विशेष रूप से फैशनेबल होना बंद हो गया है, जो कंपनी के संभावित अधिग्रहण के जोखिम को कम करता है, जिससे अप्रत्याशित रणनीतिक परिवर्तन हो सकते हैं। और, कोटलिन के लिए एक वाणिज्यिक सहायता पैकेज की कमी के बावजूद, व्यवहार में टीम जल्दी से ज्ञात समस्याओं को ठीक करती है। फिलहाल, JetBrains 1.0 रिलीज होने के एक साल बाद अगली भाषा अपडेट जारी करने का इरादा रखता है। यह रिलीज़ साइकिल कॉर्पोरेट वातावरण में विकास चक्र के समान है।

निष्कर्ष?

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