ज़ेन एर्लैंग [और एलिक्सिर - लगभग। अनुवादक]

अनुवादक से परिचय

यह लेख एर्लांग के बारे में है, लेकिन कहा गया सब कुछ समान रूप से अमृत ​​के लिए लागू होता है, एक कार्यात्मक भाषा जो एक ही BEA आभासी मशीन के शीर्ष पर चलती है। यह 2012 में दिखाई दिया और अब यह सक्रिय रूप से विकसित हो रहा है। एरलैंग के लाभों को बरकरार रखते हुए, अमृत ने सिंटैक्स को सबसे अधिक, और व्यापक मेटाप्रोग्रामिंग क्षमताओं से परिचित किया।

यह जेनेटेक द्वारा आयोजित ConnectDev'16 सम्मेलन में मेरी प्रस्तुति का एक नि: शुल्क प्रतिलेख (या एक लंबा विरोधाभास है?) है।

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

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

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

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

आने वाली गिरावट [आने वाली गिरावट - लगभग। अनुवादक ] और नियंत्रित एनीलिंग आग से अग्नि से लड़ने का एक वास्तविक उदाहरण है। Saguenay-lac-Saint-Jean में, मैं जिस क्षेत्र से आता हूं, ब्लूबेरी के खेतों को नियमित रूप से नियंत्रित करने और उनकी वृद्धि को फिर से शुरू करने में मदद के लिए जलाया जाता है। काफी बार, आप जंगल की आग को रोकने के लिए जंगल के अस्वास्थ्यकर क्षेत्रों को आग से साफ देख सकते हैं, ताकि उचित देखरेख और नियंत्रण में ऐसा हो। मुख्य लक्ष्य दहनशील सामग्री को निकालना है ताकि एक प्राकृतिक आग आगे फैल न सके।

इन सभी स्थितियों में, फसलों या जंगलों के माध्यम से आग बुझाने की विनाशकारी शक्ति का उपयोग फसलों को ठीक करने या जंगलों के बहुत बड़े, अनियंत्रित विनाश को रोकने के लिए किया जाता है।

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

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

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

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

अब हमारे पास मधुमक्खियों का झुंड है, लेकिन यदि वे किसी भी तरह से संवाद नहीं कर सकते, तो उन्हें छत्ता मजबूत करने के लिए भेजना बहुत मुश्किल होगा। जहां मधुमक्खियों का नृत्य [ मधुमक्खियों का नृत्य - लगभग। अनुवादक ], एरलांग मैसेजिंग को प्रोसेस करता है।

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

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

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

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

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

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

बदले में, अर्लंग हमें इस समस्या को हल करने के लिए दो तंत्र देता है: मॉनिटर और लिंक [ लिंक - लगभग। अनुवादक ]।

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

लिंक [ लिंक - लगभग। अनुवादक ] - द्विदिश, और एक का निर्माण दोनों संबंधित प्रक्रियाओं के भाग्य को एक साथ जोड़ता है। जब एक प्रक्रिया मर जाती है, तो इससे जुड़ी सभी प्रक्रियाएं [ निकास संकेत - लगभग] को समाप्त करने का आदेश प्राप्त करती हैं । अनुवादक ]। यह टीम, बदले में, दूसरों को [ संबंधित - लगभग मार डालती है। अनुवादक ] प्रक्रियाएँ।

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

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

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

यह पर्यवेक्षकों को बनाने का एक महत्वपूर्ण अवसर बन रहा है। हम बहुत जल्द उनके पास पहुंचेंगे।

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

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

चंद्रमा पर उतरने के रास्ते में, मॉड्यूल को अपोलो पीजीएनसीएस (प्राथमिक मार्गदर्शन, नेविगेशन और नियंत्रण प्रणाली) [ अपोलो पीजीएनसीएस - लगभग] द्वारा नियंत्रित किया गया था । अनुवादक ]। नियंत्रण प्रणाली ने चक्र [ सीपीयू - लगभग] की सावधानीपूर्वक गणना की गई संख्या के साथ कई कार्य किए । अनुवादक ] प्रत्येक। नासा ने यह भी पाया कि प्रोसेसर को अपनी क्षमता के 85% से अधिक का उपयोग नहीं किया जाना चाहिए, स्टॉक में मुफ्त 15% के साथ।

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

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

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

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

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

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

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

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

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

एर्लैंग वितरित प्रणालियों की वास्तविकता को श्रद्धांजलि देता है और उनकी रचना के लिए एक कार्यान्वयन प्रदान करता है, जो प्रलेखित और पारदर्शी है। , , - [ pylyglot systems — . ].

" ". - , . "Let it crash" , , .

— .

[ supervision trees — . ] — , . — , — — , . , — "OTP", , "Erlang/OTP" [ OTP — Open Telecom Platform — . ].

— , , , , , "" . , : , , .

, , , , — .

. " , ". , . .

. " " [ one for one — . *]. . , .

— " " [ one for all — . *]. , . , , . , . , . , , . , , !

, , , . , . : , .

, . — " " [ rest for one — . ]. , , . .

[ , — — . ] . 1 , 150 .

, , " , !"

. , , , . "" [ — . ] "" [ — . ], Jim Gray 1985 ( Jim Gray, !)

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

— , , , . , , . , , .

, , .

, — .

, . , , .

, — , , . , — ; . , , . , , , .

, , .

. , , [ Property-Based Testing Basics , Property-based testing — . ] ( ), — - , . , , , .

( ). , , .

, . , , , , . - -.

. , , , , , , .

, . Jim Gray, , , 132 , , . 131 132 , , . , , , , ; , , , 100 000 , — 10 , - .

, , .

?

, . . , . , , . , "" Facebook ( ), , , Facebook .

, , , , . , , .

, . : , , , , .

, ( ), , . , .

, , . , , , .

, , .

() . , : . Tally () , Live Reports ( ) .

, . District (; ) , (Storage). (Cache) ( ) (Worker pool).

[ supervision strategies — . ], , , , . , " ", , , . ( ) " ". , (OCR) , , . , , , , .

OCR , C , . , C, , , .

, , , . 10 , , , .

, , . , . — , .

, , , . OCR C , . OCR . . , , ( ). , , — , .

OCR , . , , — . — . , , , , - , .

, . , — - , - ( ) , . , — , . — let it crash!

. , if/else , switch ', try/catch . , , , . [ , — . ], .

, , , , . : , .

, , , . (, SMS).

, , , , , .

OTP. OTP- — , . , , . , , , . , , , .

, OTP- . OTP-, . [: OTP-, , ]

:

• , ;
• , , , ;
• , ;
• , , , , ;
• ( , );
• .

. , . , , . , — , , .

, ? , . , Heroku .

. (vegur) , , , . , , .

- , . , : 500 000 1 000 000 ! , . ? , , , 100 000 , ? - 1:17000 1:7000. , , , .

, . , , , . , . , , .

. .

, - : " , . , , , . , , . , ."

. .

, , , 60 . ( United 734), , , , - . , , , , ABS, .

( ), . , . , , .

, . ( , ) Richard Cook. , YouTube, .

- . , , , .. — ( , , ..) , , - , .

, , , . , , - - .

, , , . , . , . - - , , , .

, . , , : , . . , , , .

, , , . .

, , . , , , .

. , , , - , , , , , . , .

, 'let it crash' — , , , , , — , , , . . fail-fast , , " ", .

, . , , . . , , . Let it crash.

: , , , — . , ( , !) .