मैंने BEAM (Erlang VM) पर किताब क्यों लिखी

• Klarna के कोर सिस्टम को संभालते हुए मिले वास्तविक अनुभव में BEAM के 15 मिलीसेकंड रुकने से बड़े पैमाने पर भुगतान बाधा और आपात प्रतिक्रिया की स्थिति बनी
• BEAM पर एक भरोसेमंद reference बनाने के लिए 10 साल में यह किताब लिखी गई
• लेखन प्रक्रिया के दौरान publisher बदलना, तकनीकी समस्याएँ, कई बार संरचना बदलना जैसी बार-बार की निराशाएँ और दोबारा कोशिशें झेलीं
• ओपन सोर्स करने के बाद community feedback और भागीदारी, stars में बढ़ोतरी, और हौसला बढ़ाने वाले संदेश लगातार प्रेरणा का स्रोत बने
• मुख्य सामग्री BEAM VM की संरचना और संचालन पर केंद्रित है, और इसे व्यावहारिक इंजीनियरों के लिए वास्तविक मददगार बनाने पर जोर है

---

BEAM किताब लिखने की प्रेरणा

Post-mortems, कॉफी, और 10 साल की जिद

• Klarna में कोर payment system चलाते हुए बार-बार यह अनुभव हुआ कि BEAM का सिर्फ 15 मिलीसेकंड रुकना भी लाखों payment failures, देर रात emergency meetings, और CEO तक को बुलाने वाली स्थिति पैदा कर सकता है
• ऐसे संकट को तेज़ी से सुलझाने में मदद करने वाली सामग्री की कमी हमेशा खलती थी, और इसी सोच के साथ कि अगला engineer समस्या को और जल्दी हल कर सके, The BEAM Book लिखी गई

शुरुआती लेखन प्रक्रिया

शुरुआत और निराशा

• अक्टूबर 2012 में एक DocBook file और बड़े इरादों के साथ प्रोजेक्ट शुरू किया गया
• 2 हफ्तों के commits ज़्यादातर structure पर काम और metadata update करने में गए, असली सामग्री बहुत कम थी
• नवंबर में AsciiDoc और custom build scripts पर स्विच किया गया और 6 महीने में पूरा होने की उम्मीद थी, लेकिन लगातार rewriting और structure changes के कारण प्रगति बहुत धीमी रही

publisher के साथ सहयोग

• 2013 में O’Reilly के साथ publishing contract साइन करने के बाद Atlassian Atlas पर migration किया गया, लेकिन files खोना और chapter management की समस्याएँ बनी रहीं
• Git history असंतोष और structure fixes की लगातार कहानी से भरी हुई है
• मार्च 2015 में सिर्फ build पास कराने के लिए chapters को जबरन अलग-अलग बाँटने जैसे अस्थायी उपाय भी आज़माए गए
• 2 महीने बाद contract चुपचाप समाप्त हो गया, और साथ ही आत्मग्लानि और राहत दोनों महसूस हुईं
• Pragmatic Bookshelf के साथ दूसरी कोशिश भी धीमी प्रगति के साथ रुक गई

reset और community की भागीदारी

• जनवरी 2017 में नए repository में massive commit के जरिए पूरा migration किया गया (6622 files, 10 लाख lines), लेकिन rewriting फिर भी अटक गई
• मार्च 2017 में Asciidoctor-आधारित private GitHub repository से दोबारा शुरुआत की गई और सिर्फ ज़रूरी हिस्से कॉपी किए गए
• 2 हफ्ते बाद public करते ही बाहरी contributors द्वारा typo fixes, diagrams जोड़ना, license सहयोग जैसी गतिविधियाँ तेज़ी से शुरू हो गईं

लगातार प्रेरित रखने वाले तत्व

• मूल रूप से BEAM वास्तव में कैसे काम करता है यह समझने की व्यक्तिगत जिज्ञासा और इच्छा सबसे बड़ी प्रेरक शक्ति थी
• community के feedback और suggestions ने लिखने की इच्छा बढ़ाई, और GitHub पर stars की बढ़ती संख्या लगातार motivation देती रही
• “Please continue being awesome” जैसे encouraging issues ने मानसिक सहारे की भी बड़ी भूमिका निभाई
• Erlang और BEAM से जुड़ी academic meetings और conferences में इसका बार-बार उद्धृत होना किताब की ज़रूरत को साबित करता गया
• Twitter आदि पर लगातार mentions और shares ने भी लेखन जारी रखने के लिए प्रेरित किया

किताब की संरचना और मुख्य पाठक

• सीधे बड़े पैमाने के Erlang systems को डिजाइन और चलाने के अनुभव से, उन्हीं हिस्सों पर लिखा गया जो वास्तव में सबसे ज़रूरी थे
  • scheduler और process management: वास्तविक load में process scheduling, priority, और balancing के सिद्धांत
  • process memory: heap, stack, message, और binary management का तरीका और उसका operations पर असर
  • garbage collection और memory model: process-level/global GC का काम करने का तरीका, memory leaks, और reference structure
  • data representation system: integer, float, tuple, binary आदि data की internal tagging structure
  • compiler और VM की internal structure: compile होने के बाद VM में commands वास्तव में कैसे execute होते हैं
  • tracing और debugging: dbg, erlang:trace, message और event tracing आदि
  • performance tuning: real code profiling, latency के कारणों का विश्लेषण, reduction को समझने का तरीका
  • system architecture: ERTS, BEAM VM, और subsystems के एकीकृत काम करने के सिद्धांत
• Erlang/Elixir के production operators के लिए इसका बहुत व्यावहारिक प्रभाव है, और बिखरी हुई सामग्री की जगह एक भरोसेमंद comprehensive guide देना इसका मुख्य उद्देश्य है

लेखन प्रक्रिया से मिले सबक

• लगातार लगे रहना perfectionism पर भारी पड़ता है। दो बार publishing cancel होने के बाद भी निष्कर्ष यही रहा कि यह “अधूरा” होने से बेहतर है
• focus और boundaries तय करना महत्वपूर्ण है। लिखने का समय सुरक्षित रखना, notifications बंद करना, और सख्त time management ही वास्तविक प्रगति का स्रोत थे
• public sharing और feedback गुणवत्ता सुधार की कुंजी हैं। बाहरी proofreading, प्रोत्साहन, और लगातार मिलने वाला बाहरी stimulus बहुत मददगार रहा
• scope management अनिवार्य है। दायरा सीमित करने के लिए कठिन विषयों (Dirty Scheduler, JIT आदि) को बाद के appendix के लिए छोड़ा गया
• release के बाद iterative improvement की रणनीति महत्वपूर्ण है। BEAM हर साल बदलता है, और एक living Git repo के रूप में इसे लगातार बेहतर किया जा सकता है
• वास्तविक deadline तय करना सबसे व्यावहारिक motivation है। Code Beam Stockholm इवेंट से पहले print करना एक ऐसी deadline थी जिसने ज़रूरी सामग्री चुनने पर मजबूर किया

पूर्णता की परिभाषा

• जब पहली बार छपी हुई प्रति को हाथ में लिया, तभी सच में ‘पूरा होने’ का एहसास हुआ
• बिखरे हुए commits एक वास्तविक किताब के रूप में बंध चुके हैं, इसलिए मौजूदा स्थिति के आधार पर इसे पूर्ण घोषित किया गया

भाग लेने का तरीका

• The BEAM Book 1.0 अभी Amazon पर paperback के रूप में खरीदी जा सकती है
  • Amazon लिंक
• अगर typo या सुधार योग्य बात मिले, या internal structure के बारे में जिज्ञासा हो, तो GitHub repo पर star, fork, issue बनाना, और pull request का उपयोग किया जा सकता है
  • contributors का नाम धन्यवाद अनुभाग में वास्तविक नाम के साथ दर्ज किया जाता है
  • GitHub: theBeamBook
• चूँकि वास्तविक reviews algorithm पर अधिक असर डालते हैं, इसलिए reviews लिखने का भी सक्रिय अनुरोध है
• वास्तविक systems पर केंद्रित BEAM internals workshop भी आयोजित की जा सकती है; पूछताछ के लिए [e-mail] पर email करने को कहा गया है

[GN⁺]

Hacker News राय

• git रिपॉज़िटरी यहाँ देखी जा सकती है

• लेखक की यह प्रेरणा प्रभावशाली लगी कि वह BEAM को ठीक से समझना चाहता था, इसलिए लगातार इसकी गहराई में जाता रहा। मुझे लगता है कि ऐसी लगन ही शानदार नतीजे लाती है। इसलिए मैंने तुरंत खरीदने का फैसला किया। अपने अनुभव से कहूँ तो मुझे प्रकाशकों से कई बार किताब लिखने के प्रस्ताव मिले, लेकिन हमारी दिशा अलग होने की वजह से बात कभी बनी नहीं। उदाहरण के लिए, मैं 14 साल के बच्चों के लिए Java की शुरुआती किताब नहीं लिखना चाहता था, और प्रकाशकों की मेरे गहरे विषयों (जैसे classloader) में रुचि नहीं थी। यह जानने की उत्सुकता है कि लोग अपनी निजी लगन और पाठकों की ज़रूरतों के मिलने वाला साझा बिंदु कैसे खोजते हैं

  • तीन किताबें लिखने के अनुभव से कहूँ तो या तो self-publishing करो, या फिर वही किताब लिखो जो प्रकाशक चाहते हैं। हर प्रकाशक की अपनी शैली और प्राथमिकता होती है, और बहुत से प्रकाशक शुरुआती स्तर की practical किताबों पर ध्यान देते हैं। इसलिए अगर आप कम लोकप्रिय विषय पर लिखना चाहते हैं, तो self-publishing की तैयारी करना ही यथार्थवादी रास्ता है। अच्छी बात यह है कि आजकल self-publishing आसान हो गई है और ऑनलाइन बेचना भी संभव है। यानी अगर विषय बहुत niche market के लिए है, तो प्रकाशक से उम्मीद न करके खुद ही publishing और marketing संभालनी पड़ती है
  • अगर आप सच में दिलचस्प बात कह रहे हैं, तो पाठक आखिरकार उसे समझने का तरीका ढूँढ ही लेते हैं। अपने करियर की शुरुआत में मैंने Don Box की “Essential .Net” पढ़ी थी, और वह भी किसी खास पाठक वर्ग को निशाना बनाकर लिखी हुई नहीं लगी। वह बस CLR के अंदरूनी हिस्सों को बहुत गहराई से खंगालने वाली किताब थी, और उसे पूरी तरह समझने के लिए शुरुआत में कई बार पढ़ना पड़ता था
  • मैं इस पर सोच रहा हूँ कि क्या प्रकाशक पर निर्भर रहना ज़रूरी है, या क्या किताब पूरी तरह स्वतंत्र रूप से खुद भी लिखी जा सकती है। सोचता हूँ कि क्या यह प्रकाशक के नाम या किसी अतिरिक्त फ़ायदे की वजह से होता है
  • मैं इस बात से सहमत हूँ कि सिखाना सीखने का सबसे अच्छा तरीका है। यह मैंने स्कूल में गणित tutoring करते समय सीखा था, और किताब लिखना भी कुछ वैसा ही अनुभव है। यह सिर्फ समझ लेने से आगे बढ़कर बुनियादी बातों को सच में अपना बना लेने का सबसे अच्छा तरीका है
  • थोड़ा शेख़ी जैसा लगेगा, लेकिन मैंने भी इसी तरह climbing के लिए strength training पर एक किताब लिख डाली। शुरू में self-publishing करने का इरादा था, लेकिन अंत में एक प्रकाशक ढूँढ लिया और किताब को थोड़ा ज़्यादा readable बनाने के लिए संपादित किया। सीधे प्रकाशकों से संपर्क करना भी एक तरीका हो सकता है

• पिछले एक साल में BEAM और Erlang/OTP के साथ काम करना मेरे सबसे अच्छे development अनुभवों में से एक रहा है। मैंने Joe Armstrong की “Programming Erlang: Software for a Concurrent World” इस्तेमाल की, और शुरुआती लोगों को इसे मज़बूती से recommend करना चाहूँगा। “Designing for Scalability with Erlang/OTP” की भी अच्छी प्रतिष्ठा है, लेकिन मैं अभी तक उसे शुरू नहीं कर पाया हूँ। लेकिन गहराई के मामले में यह नई किताब कहीं आगे है। BEAM सच में किसी प्राचीन सभ्यता की छोड़ी हुई alien technology जैसा लगता है। सही समय पर यह किताब आ गई, इसलिए मैंने तुरंत खरीद ली। दो बार प्रकाशन रद्द होने के बाद भी किताब पूरी करने के लिए Erik Stenman को सलाम

  • जानना चाहूँगा कि आपने BEAM/Erlang/OTP से किस तरह का software बनाया है

• Elixir और BEAM network-based या pipeline-heavy systems बनाने के लिए मेरी सबसे पसंदीदा पसंद हैं। मैंने इन्हें कई साल production में रोज़ इस्तेमाल किया है, और हाल की projects में भले चुनाव आसान नहीं रहा, फिर भी मैं लगातार इनकी दिशा पर नज़र रखता हूँ। इस किताब के प्रकाशित होने के लिए आभारी हूँ। कुछ साल पहले production Elixir में debugging करते समय मुझे ठीक ऐसी ही किताब की बहुत ज़रूरत थी। जो सामग्री उपलब्ध थी, वह या तो बहुत कठिन थी या फिर बहुत सतही

• BEAM (Erlang virtual machine) की जानकारी Wikipedia लिंक पर देखी जा सकती है

  • किताब का शीर्षक ही इसे अच्छी तरह समझा देता है

• मुझे लगता है कि BEAM open source दुनिया की सबसे कम आंकी गई technologies में से एक है। उदाहरण के लिए whatsapp है। यह रहस्य है कि Elixir और Erlang high-concurrency projects में और ज़्यादा लोकप्रिय क्यों नहीं हैं

  • मेरी नौकरी Erlang विशेषज्ञ कंपनी में है। Erlang की असली ताकत बड़े पैमाने के traffic, जैसे लाखों DAU, में दिखती है। Elixir से हज़ारों DAU वाली वेबसाइट चलाई जा सकती है, लेकिन Erlang और BEAM का सार उस पैमाने पर सामने आता है। इतनी scale की ज़रूरत बहुत कम कंपनियों को होती है, और उससे भी बड़ी समस्या यह है कि Erlang ecosystem खुद एक अलग OS की तरह व्यवहार करता है, इसलिए environment setup और components काफ़ी जटिल हो जाते हैं। container या k8s जैसी दूसरी infrastructure technologies की भी ज़रूरत नहीं पड़ती, और Erlang का अपना तरीका लोगों को अपरिचित लग सकता है। लेकिन अगर सही use case में Erlang का अनुभव मिले, तो वह किसी जादू जैसा लगता है। यह मेरे करियर की highlights में से एक है
  • आख़िरकार मुझे लगता है कि यह marketing का असर है। Java, C#, Go जैसी भाषाओं को बहुत शक्तिशाली corporate backing मिली हुई है, जबकि Erlang को कंपनियाँ या तो पीछे खींचती रही हैं या technical documentation से आगे बहुत ध्यान नहीं देतीं। Elixir पहली भाषा थी जिसने अलग तरह की language marketing, यानी Ruby मॉडल, अपनाया, लेकिन उसका समय और परिस्थितियाँ अलग थीं। developers को BEAM की खूबियाँ समझ आती हैं, लेकिन बाकी decision-makers तक उसकी अपील शायद ठीक से नहीं पहुँचती
  • मुझे लगता है कि investment का अंतर बहुत बड़ा है। Rust, Go, Python आदि में corporate support के कारण static analysis, type checking, developer experience जैसी चीज़ों में काफ़ी निवेश हुआ है, जबकि Erlang को इस तरह का प्यार पर्याप्त नहीं मिला। बड़े उपयोगकर्ता भी धीरे-धीरे BEAM के बाहर सीधे समाधान बनाने लगे हैं या दूसरी दिशा में जा रहे हैं
  • हमने हाल ही में एक Squarespace वेबसाइट को Phoenix application में बदला, और यह सच में बहुत आनंददायक अनुभव था
  • साथ ही यह सबसे कम गुप्त ‘secret sauce’ भी है। हाल ही में BBC ने भी Elixir की ओर रुख किया है, इसलिए लगता है कि इसकी लोकप्रियता धीरे-धीरे बढ़ रही है

• “Erlang Runtime System(ERS)” सामान्य Erlang runtime के लिए और “Erlang RunTime System(ERTS)” Ericsson implementation तक सीमित अभिव्यक्ति है — यह व्याख्या अच्छी लगी

  • मुझे नहीं लगता कि यह परिभाषा बेवकूफ़ी भरी है

• मैंने तुरंत किताब खरीद ली। इसे ऑनलाइन मुफ़्त में पढ़ा जा सकता है, लेकिन मैं लेखक को थोड़ा-बहुत support देना चाहता था इसलिए खरीदी

• मैं Klarna जैसे बड़े सिस्टम पर काम नहीं करता, इसलिए यह समझना कठिन है कि 15ms delay भी postmortem issue बन सकता है

  • BEAM में microsecond (μs) स्तर का response सामान्य होता है, इसलिए अगर latency millisecond (ms) तक उछल जाए तो तुरंत alarm बज सकता है
  • BEAM systems में ऐसी स्थिति पूरी तरह हो सकती है। अगर shared state की सुरक्षा के लिए gen_server बनाया जाए, तो वह एक विशाल mutex जैसा काम करता है। मान लीजिए gen_server को एक request संभालने में 20us लगते हैं, तो 15ms delay का मतलब message queue में 750 messages जमा होना है। अगर इस queue को inefficient pattern से इस्तेमाल किया जाए, तो performance बहुत तेज़ी से गिरती है। BEAM केवल कुछ खास patterns के लिए message queue optimization करता है, बाकी मामलों में queue की लंबाई के साथ processing time बढ़ता जाता है। अगर किसी library के अंदर unsafe receive इस्तेमाल हो, तो अप्रत्याशित performance degradation हो सकती है। हाल में BEAM ने message queue समस्याओं को कम करने के लिए 'alias' feature जोड़ा है, लेकिन बहुत-सी libraries अभी इसका उपयोग नहीं करतीं। alias का मकसद message loss रोकना है, और यह timeout messages से queue के प्रदूषित होने से भी बचाता है। आम तौर पर long-lived processes queue को loop में घुमाकर process करती हैं
  • अगर किसी के पास उस घटना का postmortem लिंक हो तो जानना चाहूँगा। मुझे ऑनलाइन नहीं मिला

• जानना चाहता हूँ कि क्या BEAM जैसी कोई और VM भी है। क्या BEAM इतनी बेहतरीन है कि उसके प्रतिस्पर्धी ही नहीं हैं, या फिर उसे बनाना ही इतना कठिन है

  • मुझे लगता है कि आधुनिक Kubernetes infrastructure कई मामलों में BEAM जैसी क्षमताएँ देती है। आजकल ऐसी infrastructure के साथ बड़े self-healing systems बनाए जाते हैं, और भाषा की भी बाधा नहीं होती। Erlang/Elixir के अलावा भी कई ecosystems, प्रतिभाएँ और रुचियाँ मौजूद हैं
  • AtomVM नाम की एक अलग implementation भी है, जो IoT जैसे constrained devices के लिए है। BEAM या OTP को दूसरे ecosystems में लागू करने की कई कोशिशें हुई हैं, लेकिन ज़्यादातर VM स्तर पर नहीं थीं
  • 90 के दशक के आखिर और 2000 के शुरुआती वर्षों में जब BEAM आया था, तब वह काफ़ी अनोखा था। आज वही समस्याएँ अलग implementations के साथ कई भाषाओं और tools द्वारा अच्छी तरह हल की जा सकती हैं। Erlang community में “सिर्फ BEAM का तरीका ही सही है” जैसा एक रवैया भी मिलता है, लेकिन 2025 में सचमुच बहुत सारे विकल्प मौजूद हैं। BEAM-compatible implementations भी हैं, लेकिन ज़्यादातर niche क्षेत्रों में। अगर आपको मौजूदा BEAM infrastructure से जुड़ना नहीं है, तो greenfield project के लिए आज के ecosystem के modern solutions ज़्यादा उपयुक्त लगते हैं। ergo जैसा छोटा project भी है
  • शायद Dis VM सबसे मिलता-जुलता है, और उसके बाद Smalltalk VM। सच तो यह है कि BEAM की असली ताकत तब दिखती है जब उसके ऊपर OTP बैठा हो
  • व्यावहारिक उपयोग में सबसे क़रीब शायद Go है। BEAM का ecosystem “Erlang-प्रकार की भाषाओं” के लिए बना है, इसलिए Elixir या Gleam में भी core behavior Erlang जैसा ही रहता है। Go goroutine जैसी concurrency primitives देता है, लेकिन OTP की तरह application structure के बारे में कोई स्पष्ट दृष्टिकोण नहीं देता