जंग कमाल है, कुछ खास चीजों के लिए। लेकिन स्टार्टअप के लिए इसे चुनने से पहले दो बार सोचें, जिसे तेजी से आगे बढ़ने की जरूरत है।

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

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

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

रस्ट से मेरा प्राथमिक अनुभव पिछले स्टार्टअप में 2 साल से थोड़ा अधिक समय तक काम करने से आता है। यह प्रोजेक्ट क्लाउड-आधारित SaaS उत्पाद था, जो कमोबेश एक पारंपरिक CRUD ऐप है: यह माइक्रोसर्विसेज का एक सेट है जो एक डेटाबेस के सामने एक REST और gRPC API समापन बिंदु प्रदान करता है, साथ ही कुछ अन्य बैक- एंड माइक्रोसर्विसेज (खुद को रस्ट और पायथन के संयोजन में लागू किया गया)। रस्ट का मुख्य रूप से उपयोग किया गया था क्योंकि कंपनी के कुछ संस्थापक रस्ट विशेषज्ञ थे। समय के साथ, हमने टीम में काफी वृद्धि की (इंजीनियरिंग हेडकाउंट को लगभग 10 गुना बढ़ा दिया), और कोडबेस का आकार और जटिलता भी काफी बढ़ गई।

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

कटा हुआ ब्रेड के बाद से जंग को सबसे अच्छी चीज माना जाता है, तो यह हमारे लिए इतना अच्छा काम क्यों नहीं कर रहा था?

रस्ट में एक विशाल सीखने की अवस्था है।

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

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

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

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

उन समस्याओं को ठीक करने के अन्य तरीके हैं जिन्हें रस्ट हल करने का प्रयास कर रहा है।

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

रस्ट ने निर्णय लिया है कि डेवलपर उत्पादकता की तुलना में सुरक्षा अधिक महत्वपूर्ण है। यह कई स्थितियों में बनाने के लिए सही ट्रेडऑफ़ है - जैसे OS कर्नेल में बिल्डिंग कोड, या मेमोरी-विवश एम्बेडेड सिस्टम के लिए - लेकिन मुझे नहीं लगता कि यह सभी मामलों में सही ट्रेडऑफ़ है, विशेष रूप से स्टार्टअप्स में नहीं जहाँ वेग महत्वपूर्ण है। मैं एक व्यावहारिक हूँ। इन समस्याओं से पूरी तरह से बचने के लिए डिज़ाइन की गई भाषा का उपयोग करने के लिए टीम में हर किसी को 4x उत्पादकता हिट होने के बजाय, मैं अपनी टीम को कभी-कभी स्मृति रिसाव या कोड में लिखे गए कोड के लिए टाइप त्रुटि को डीबग करने में समय बर्बाद कर दूंगा । .

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

आपको रस्ट डेवलपर्स को काम पर रखने में कठिनाई होगी।

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

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

पुस्तकालय और दस्तावेज अपरिपक्व हैं।

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

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

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

रस्ट नए फीचर्स को रफ आउट करना बहुत कठिन बना देता है।

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

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

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

जंग किसमें अच्छी है?

रस्ट के बारे में निश्चित रूप से कुछ चीजें हैं जो मुझे पसंद हैं, और रस्ट की विशेषताएं जो मुझे अन्य भाषाओं में पसंद हैं। वाक्य - matchविन्यास बढ़िया है। , Option, Resultऔर Errorविशेषताएँ वास्तव में शक्तिशाली हैं, और ?ऑपरेटर त्रुटियों को संभालने का एक सुंदर तरीका है। इनमें से कई विचारों के अन्य भाषाओं में समकक्ष हैं, लेकिन उनके साथ रस्ट का दृष्टिकोण विशेष रूप से सुरुचिपूर्ण है।

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

ठीक है, अब जब मैंने हैकर न्यूज के आधे पाठकों को पर्याप्त रूप से नाराज कर दिया है, तो मुझे लगता है कि अब मेरे अगले लेख के विषय की घोषणा करने का उतना ही अच्छा समय है: nanoबेहतर पाठ संपादक क्यों है। आपसे अगली बार मिलेंगे!