Erlang के lightweight processes और message passing के बारे में नहीं, इसकी असली बात (2023)

पृष्ठभूमि

• Erlang एक ऐसी भाषा है जिसे भरोसेमंद distributed systems बनाने के लिए विकसित किया गया था। इसकी शुरुआत Prolog library के रूप में हुई थी और बाद में यह एक स्वतंत्र भाषा के रूप में विकसित हुई।
• इसे Ericsson में telephone switch programming के लिए इस्तेमाल किया गया था, और 1998 में इसे open source कर दिया गया।
• Joe Armstrong, Erlang के प्रमुख डिज़ाइनरों में से एक थे, और उनकी doctoral thesis इस बात पर केंद्रित थी कि software faults मौजूद होने पर भी भरोसेमंद distributed systems कैसे बनाए जाएँ।

Behaviours

• Erlang में behaviours, Java या Go के interfaces जैसे हैं; ये type signatures का एक संग्रह होते हैं जिनके कई implementations हो सकते हैं।
• Behaviours की मदद से आपको केवल program की business logic परिभाषित करने वाला code लिखना होता है, जबकि infrastructure code अपने आप उपलब्ध कराया जाता है।
• Behaviours विशेषज्ञों द्वारा लिखे जाते हैं और best practices पर आधारित होते हैं।

General server behaviour

• gen_server को key-value store implement करने वाले उदाहरण से समझाया गया है।
• handle_call state को update करने या key lookup करने का काम करता है, और सारी concurrency gen_server component के अंदर छिपी रहती है।

Event manager behaviour

• gen_event एक event manager है, जो event handlers को register करता है और message आने पर उन्हें चलाता है।
• यह error logging के लिए उपयोगी है, और एक सरल logger example दिया गया है।

State machine behaviour

• gen_fsm का नाम बदलकर gen_statem कर दिया गया है, और यह protocols को implement करने के लिए उपयुक्त है।

Supervisor behaviour

• Supervisor यह सुनिश्चित करते हैं कि दूसरे processes सही तरह से काम कर रहे हैं, और failure होने पर predefined strategy के अनुसार उन्हें restart करते हैं।
• one_for_one strategy में केवल failed process restart होता है, जबकि one_for_all strategy में एक process fail होने पर सभी child processes restart हो जाते हैं।

Application और release behaviour

• Application में supervisor tree और उससे जुड़ी सारी आवश्यक चीजें शामिल होती हैं, जबकि release एक या अधिक applications को package करता है।
• Upgrade fail होने पर rollback संभव होना चाहिए।

Behaviours का implementation

• Erlang के lightweight processes और message passing से अधिक, behaviours की संरचना ही भरोसेमंद software तक ले जाती है।
• दूसरी भाषाओं में behaviours implement करने के लिए interface signatures से शुरुआत की जा सकती है।

Behaviours की शुद्धता

• Simulation testing distributed systems की testing को आसान बनाती है, और gen_server behaviour की संरचना का उपयोग करके troubleshooting को सरल बनाया जा सकता है।

योगदान

• Martin Thompson के काम से ideas लेकर fast event loop बनाना, asynchronous I/O जोड़ना जैसी दिशाओं में काम करने के विचार हैं।
• यदि आपकी रुचि हो, या आपके पास राय, सुझाव, या प्रश्न हों, तो संपर्क किया जा सकता है।

[GN⁺]

Hacker News राय

• Erlang और BEAM की हैरान करने वाली बात इसकी क्षमताओं की गहराई है। OP के लिए Erlang का Behavior/Interface सबसे बड़ा हासिल था। व्यक्तिगत रूप से, मुझे लगता है कि जटिल सिस्टम बनाने के लिए आवश्यक डेवलपमेंट resources दूसरी भाषाओं की तुलना में बहुत कम लगते हैं। बहुत से लोगों के लिए lightweight processes और programming model आकर्षक हैं

  • OTP में बहुत अधिक functionality शामिल है। हम Elixir को iOS devices पर चलाने योग्य compile करने पर काम कर रहे हैं। Erlang की ei library का उपयोग करके C में nodes compile किए जा सकते हैं और दूसरे Erlang nodes के साथ interface किया जा सकता है। Erlang की rpc library के जरिए C से function calls और Elixir applications के साथ interface करना संभव है
  • Erlang ने उन कई समस्याओं को पहले ही हल कर लिया था जिनसे modern tech stack जूझते हैं, और scalability तथा implementation cost की समस्याएँ दशकों पहले सुलझा दी थीं। लेकिन HN में Erlang/Elixir को लेकर रुचि वास्तविक adoption में नहीं बदली, और कई कंपनियाँ उस चीज़ को लागू करने में पैसा बर्बाद कर रही हैं जो Erlang stack में मुफ़्त में मिलती है

• मैंने कुछ managers के साथ मिलकर उन लोगों के साथ काम किया है जो अपने अनुभवों के आधार पर किताब लिखना चाहते थे। हम सफलता के कारणों पर हमेशा असहमत रहते थे। कुछ लोग कहते हैं कि lightweight processes और message passing कोई गुप्त सूत्र नहीं हैं, लेकिन वे यह चूक जाते हैं कि Erlang का Communicating Sequential Processes इन विशेषताओं से अलग नहीं किया जा सकता

  • उदाहरण: application programmer sequential code लिखता है, और सारी concurrency behaviors के भीतर छिपी रहती है
  • नए team members के लिए शुरुआत करना आसान होता है: business logic sequential होती है और उस जैसी संरचना वे पहले देख चुके हो सकते हैं
  • supervisors और "let it crash" दर्शन भरोसेमंद systems बनाने में योगदान देते हैं

• lightweight processes और message passing की वजह से मेरी Erlang में फिर से रुचि जगी। अभी तक behaviors मेरे लिए द्वितीयक रहे थे

  • प्रोजेक्ट का उद्देश्य visual Flow Based Programming(FBP) को Erlang में लाना है। FBP Erlang के लिए उपयुक्त लगता है, और यह जानकर आश्चर्य हुआ कि यह पहले से मौजूद है
  • हम FBP के tool के रूप में Node-RED का उपयोग कर रहे हैं, और मूल विचार यह है कि Node-RED frontend को Erlang backend से जोड़ा जाए और सभी nodes को processes बना दिया जाए

• मैं यह जानकारी खोज रहा था कि Ericsson ने Erlang का उपयोग क्यों बंद किया और Joe की नौकरी से निकाले जाने के बारे में क्या हुआ

  • छोटा जवाब यह है कि नए projects के लिए Java पर जाने के कारण Erlang हाशिए पर चला गया। Joe और उनके साथियों ने 1998 में Bluetail की स्थापना की थी, जिसे Nortel ने अधिग्रहित कर लिया। Nortel एक telecom दिग्गज था, जिसके शेयर 2000 में $125 तक पहुँचे थे, लेकिन 2002 में $1 से नीचे गिर गए। यह dot-com bubble के फूटने और telecom spending में कमी से जुड़ा था

• Erlang/Elixir की ताकत Actor model implementation, Prolog matching, immutability, behaviors आदि में नहीं, बल्कि Joe की इस इच्छा में है कि कम resources से ज़्यादा काम करके दिखाया जाए

  • यह एक अच्छी तरह से डिज़ाइन किया गया, सुसंगत system है, और इसमें वैसी consistency है जो दूसरी भाषाओं में कम ही देखने को मिलती है। यह परिपूर्ण नहीं है, लेकिन प्रभावशाली है
  • मुझे लगता है कि software world में simplicity की ताकत के प्रति समझ और स्वीकार्यता की कमी है

• Erlang, OTP, और BEAM behaviors से कहीं अधिक देते हैं। VM एक virtual kernel जैसा है और supervisors, isolated processes, तथा distributed mode प्रदान करता है। OTP उपयोगी modules देता है जैसे Mnesia(database), atomic counters/ETS tables(caching) आदि

  • एक साल पहले, मैंने अपनी consulting company में Erlang को backend language के रूप में अपनाया। BEAM के भीतर जाकर TCP-based stack को QUIC से बदला और Rust patches को integrate किया

• Erlang/BEAM में सबसे दिलचस्प अवधारणा यह है कि partial recovery डिफ़ॉल्ट रूप से built-in है। जब कोई अप्रत्याशित state आती है, तो पूरे process को बंद करने या corruption का जोखिम उठाने के बजाय, सिस्टम को जितना संभव हो उतने सूक्ष्म स्तर पर ज्ञात अच्छी state तक rollback किया जाता है

• Erlang की behavior संरचना को दूसरे languages और library designers इसलिए नहीं अपनाते, क्योंकि Erlang के behavior function signatures इसकी दूसरी विशेषताओं, खासकर immutability के विशिष्ट उपयोग, से गहराई से जुड़े हुए हैं

  • दूसरी भाषाओं में वही लक्ष्य हासिल करने के लिए Erlang के तरीके को सीधे कॉपी नहीं करना चाहिए। Erlang के भरोसेमंद software से सीखना ज़रूर चाहिए, लेकिन Erlang के तरीके को ज्यों का त्यों दूसरी भाषाओं में port करने का मैं कड़ा विरोध करता हूँ

• मैं इस लेख की बात से सहमत नहीं हूँ। behaviors सिस्टम की मूल architecture की वजह से संभव हैं। behaviors interfaces नहीं, बल्कि Java जैसी भाषाओं के abstract objects के अधिक समान हैं

  • Joe का paper दिखाता है कि दिए गए Lego blocks के सेट से भरोसेमंद systems कैसे बनाए जाएँ

• behaviors इतने भी दिलचस्प नहीं हैं। वे दूसरी programming languages में भी मौजूद हैं। BEAM की दिलचस्प बात यह है कि exceptions throw करना बेहद elegant है। exceptions throw करने और behaviors की ताकत यह है that errors को catch करना, context information report करना, और सामान्य रूप से composition को आसान बनाना संभव हो जाता है