मेरा सबसे पसंदीदा Erlang प्रोग्राम (2013)

 (joearms.github.io)
2 पॉइंट द्वारा GN⁺ 2023-09-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • उपलब्ध नोट्स की सीमा के आधार पर यह तय नहीं किया जा सकता कि शीर्षक में उल्लिखित Erlang प्रोग्राम क्या है या वह क्यों महत्वपूर्ण है
  • सत्यापित किया जा सकने वाला पाठ मुख्यतः Shell स्क्रिप्ट के अंशों और एक छोटे सुधार-वाक्य तक सीमित है
  • स्क्रिप्ट वर्तमान डायरेक्टरी में *.png.png.meta फ़ाइलों पर लूप चलाती है और फ़ाइलनाम से पहले डॉट से पहले वाला भाग निकालती है
  • वास्तव में चलाया जाने वाला कमांड git mv $i $j.png.meta है, और $j.png.png को $j.png में बदलने वाला कमांड केवल प्रिंट किया जाता है
  • मूल पाठ के chunk 5-104 हटाए गए हैं, इसलिए शीर्षक से जुड़े मुख्य दावे या Erlang कोड की व्याख्या की पुष्टि नहीं की जा सकती

सत्यापित की जा सकने वाली सामग्री

  • उपलब्ध दायरे के आधार पर “सबसे पसंदीदा Erlang प्रोग्राम” की पहचान, पसंद किए जाने का कारण, या कोड संरचना तय करना कठिन है
  • सत्यापित किया जा सकने वाला कोड अंश #!/bin/sh से शुरू होने वाली फ़ाइलनाम बदलने की Shell स्क्रिप्ट है
    • यह *.png.png.meta फ़ाइलों को लक्षित करती है
    • j="${i%%.*}" के जरिए फ़ाइलनाम से पहले डॉट से पहले वाला भाग निकाला जाता है
    • git mv $i $j.png.meta वास्तव में चलाया जाता है
    • git mv $j.png.png $j.png को केवल echo के जरिए प्रिंट किया जाता है
  • “Actually you don't need the really do this. It should have been water the plants.” जैसा एक वाक्य है, जिसे इस रूप में पढ़ा जा सकता है कि पिछला निर्देश या उदाहरण वास्तव में आवश्यक नहीं था और उसकी जगह “water the plants” होना चाहिए था
  • अंत में Joe Armstrong और Jeremy Ruston का साथ में उल्लेख है

निर्णय को सीमित करने वाला संदर्भ

  • कई chunk TiddlyWiki state/sidebar metadata, JPEG/PNG जैसे दिखने वाले Base64 data, और खाली सामग्री से बने हैं, इसलिए मुख्य लेख से तथ्य निकालना कठिन है
  • उपलब्ध नोट्स में Erlang प्रोग्राम के व्यवहार, कोड, डिज़ाइन कारण, उदाहरण, संख्याएँ, workflow, या दावों जैसी मुख्य जानकारी शामिल नहीं है
  • Shell स्क्रिप्ट का अंश भी आसपास के स्पष्टीकरण के बिना केवल आंशिक रूप में दिया गया है, इसलिए यह तय नहीं किया जा सकता कि यह किस काम का हिस्सा है

हटाया गया दायरा

  • इनपुट में स्पष्ट रूप से कहा गया है कि मूल पाठ के chunk 5-104 लंबाई/लागत सीमा के कारण हटाए गए हैं
  • यह सारांश केवल उपलब्ध नोट्स की सीमा को दर्शाता है और मूल पाठ के पूरे विवरण या निष्कर्ष को समेटता नहीं है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-09-09
Hacker News की राय

  • अगर server closure F अपने खुद के messages के अलावा {become, F} message भी ले सकता है, तो server को लगातार नए behavior में बदला जा सकता है
    बात थोड़ी अलग है, लेकिन Erlang conference में Joe से हुई बातचीत याद रह गई। वे हमेशा technology को लेकर उत्साहित रहते थे और किसी से भी बात करने को तैयार रहते थे। वे दुखी थे कि Windows हर साल और खराब और कम उपयोगी होता जा रहा है, और उन्होंने कहा था कि किसी दिन file देखने के लिए unlock होने से पहले कुछ देर ads देखने पड़ेंगे—और वे लगभग सही साबित हो रहे हैं। Windows 11 में पहले से ads हैं, और उन्हें हटाने के लिए जान-बूझकर settings ढूंढनी पड़ती हैं, तो Windows 13 तक शायद सच में ऐसा ही हो जाए

    • घर पर Linux और काम पर Windows इस्तेमाल करता हूं, लेकिन ads से भी ज्यादा चौंकाने वाली बात यह है कि Windows में वे अजीब समस्याएं अब कहीं ज्यादा दिखती हैं जो पहले पुराने Linux में दिखती थीं
      जैसे एक earbud की आवाज़ बहुत ज्यादा तेज़ होना, Microsoft apps का अजीब तरह से crash हो जाना, Windows documentation page का किसी भी browser में न खुलना इसलिए archive sites का इस्तेमाल करना पड़ना, जो external monitor ठीक से detect हो रहा था उसे अचानक न detect कर पाना या screen का flicker करना। Office default रूप से local के बजाय cloud में save कराने की ओर धकेलता है, लेकिन मेरी राय में files local-first होनी चाहिए और cloud backup के लिए हो तो अच्छा है। WSL काफी खुरदरा है, लेकिन Windows इस्तेमाल कर पाने की लगभग अकेली वजह भी वही है
      मैंने हमेशा सुना कि Joe बेहतरीन इंसान थे, और यह बात समझ आती है। जब मैं शुरुआत में खुद coding सीख रहा था, मैंने उनकी Erlang book पढ़ी थी; उनकी playful शैली, विनम्रता और कल्पनाशीलता ने गहरा असर डाला। Erlang का इस्तेमाल मुझे लगभग कभी नहीं करना पड़ा, लेकिन उनके लेखन ने code के बारे में सोचने का तरीका बदल दिया, और काश math, software engineering और computer science culture playfulness और humility को अधिक अपनाएं
    • पहले paragraph में जो बात है, वह असल में actor model की capability है। मुझे पहले नहीं पता था कि BEAM में भी यह संभव है
    • Windows 11 के intrusive ads कोई नई चीज़ नहीं हैं। वे पहले से Windows 10 में भी मौजूद हैं

  • BEAM, JVM या Node जैसी दूसरी virtual machines से क्यों अलग है, यह समझाने वाला 35 मिनट का छोटा overview video: https://www.youtube.com/watch?v=pO4_Wlq8JeI

    • इसी तरह की talk The Soul of Erlang and Elixir देखी थी; बहुत अच्छी थी, और हर बार देखने पर फिर से उत्साह बढ़ जाता है

  • Joe की याद आती है। computing को बेहतर बनाने का उनका contagious जुनून मेरे युवा दिनों के मुझ पर और आज technology के प्रति मेरे approach पर गहराई से असर छोड़ गया है

  • universal_server() -> receive {become, F} -> F() end.
    सच कहूं तो इस universal_server की ताकत पूरी तरह समझ नहीं पा रहा हूं। कोई समझा दे तो अच्छा होगा

    • अगर आप Go से परिचित हैं, तो यह कुछ वैसा है जैसे कोई goroutine जो किसी के anonymous function भेजने और उसे execute करने का इंतज़ार कर रही हो
      Erlang में समस्या हल करने के लिए बहुत सारे processes चलाए जाते हैं, और ज्यादातर processes messages का इंतज़ार करते हैं। अहम फर्क यह है कि Erlang process remote machine पर भी seamless तरीके से चल सकता है। यह process become नाम के atom और function वाला tuple message लेता है, और कोई भी दूसरा process जब भी वह message भेजे, तो यह उस function में “बदल” जाता है
      यानी waiting loop की logic को आप अपनी पसंद की protocol logic से बदल सकते हैं। उदाहरण में कई machines पर यह loop चलाकर gossip protocol implement करने वाला function भेजा गया था, लेकिन उसी तरह BitTorrent client बनने वाला message भी भेजा जा सकता है। Joe genius होने के साथ-साथ बहुत दयालु इंसान भी थे, और Erlang अब तक देखी गई सबसे सुंदर technical creations में से एक है। यह concurrency को पूरी तरह नए ढंग से दिखाता है
    • थोड़ा और खोलकर कहें तो, receive keyword आने वाले messages पर switch statement जैसा लगता है, लेकिन असल में यह pattern matching है
      उदाहरण के लिए {From, N} लेकर From ! factorial(N) से result वापस भेजने वाला factorial server बनाया जा सकता है। ! result को return process को भेजने वाला operator है
      test code universal_server चलाता है, फिर Pid ! {become, fun factorial_server/0} से उसे factorial server बनाता है, और {self(), 50} भेजकर 50 का factorial वापस लेता है। Erlang की बड़ी खूबियां distributed parallelism और hot code update हैं, और यहां यह universal_server के receive loop को factorial_server के receive loop से overwrite करने के रूप में दिखता है। हालांकि असली hot code update ठीक इसी तरह काम नहीं करता, ऐसा लगता है
    • आमतौर पर server किस काम में आएगा, यह पहले से जानकर code लिखना पड़ता है
      लेकिन Erlang में distributed Erlang servers का network बनाया जा सकता है, और servers को client की इच्छानुसार काम करने वाला general-purpose compute resource रखा जा सकता है। code client से आता है, और हर machine पर binary install करने के लिए system administrator से कहने की जरूरत नहीं; function pass करने पर remote machine उसे call कर देती है
    • मुख्य बात यह है कि यह आपकी पसंद के किसी भी तरह के server में बदल सकता है
      server चलाने वाला actual function client देता है, और Erlang process उसी function के आधार पर वह server बन जाता है। Erlang की hot reloading क्षमता को ध्यान में रखें तो यह simple structure और भी शक्तिशाली हो जाता है। Erlang process काम का इंतज़ार करता compute resource है, और अगर वह काम पूरा server चलाना हो, तो यह काफी शानदार है
    • Erlang की बनावट अलग है: virtual machine और language दोनों इसी idea पर बनी हैं कि छोटे-छोटे processes साथ-साथ चलते हैं और हर process incoming messages को interpret करने के लिए infinite loop में इंतज़ार करता है
      इसलिए process आपके भेजे code के आधार पर कुछ भी बन सकता है। अगर उसे microwave control करना हो, फिर quantum calculation करनी हो, और अगले दिन football match का विजेता predict करना हो, तो हर काम के लिए जरूरी code भेजें और वह वैसा ही करेगा

  • BEAM क्यों खास है, और Erlang/Elixir आदि की concurrency Go या Java की concurrency से क्यों अलग है—यह समझाने में मैं काफी समय लगाता हूं
    अब से लगता है Joe के favorite Erlang program और इस HN thread का link देना ही काफी होगा

  • यह blog post हाल की एक शानदार presentation में भी cover की गई थी: https://youtu.be/pQ0CvjAJXz4

    • high availability, fault tolerance, distributed Erlang system architecture के हर चरण को बहुत अच्छी तरह cover और explain करने वाली presentation है
    • क्या यह वही system है जिसमें हर patient को एक Erlang process के रूप में represent किया जाता है

  • Erlang के बारे में मुझे भाषा की सिर्फ़ high-level समझ है और मैंने उसमें सीधे programming नहीं की है, इसलिए जिज्ञासा है कि इस code की ज़रूरत क्यों है
    universal_server() -> receive {become, F} -> F() end.
    ऐसा लगता है कि remote machine पर सीधे F() चला देना ही काफ़ी होना चाहिए। remote virtual machine में F का code पहले से होना चाहिए, इसलिए इस example का मतलब यह भी हो सकता है कि F के code को serialize करके भेजा जा रहा है। अगर यह common boilerplate संभालता है तो इसकी उपयोगिता समझ आती है, लेकिन अभी तो यह become F message का इंतज़ार करके F() execute करने जैसा दिखता है

    • यह code शानदार है, लेकिन शायद बहुत idiomatic नहीं है या real production code में अक्सर दिखने वाला तरीका नहीं है। फिर भी Joe को exploration और experimentation पसंद था
      यहाँ F एक closure है, इसलिए इसमें सिर्फ़ code ही नहीं, बल्कि captured variables और creation के समय का environment भी शामिल हो सकता है। F() call करने पर वह code चलता है और उस surrounding environment तक access कर सकता है जिसमें F बना था
      Erlang में closure को network के पार दूसरे Erlang node पर भेजा जा सकता है। हालांकि closure जिन module code को reference करता है, वे सभी nodes पर मौजूद होने चाहिए। production code में, जैसा आपने कहा, शायद F module को सीधे call किया जाएगा और arguments साफ़ तौर पर pass किए जाएंगे; यह ज़्यादा एक cool demo है जो संभावना दिखाता है
    • Erlang के functional design की वजह से F() पिछले किसी भी context जितना ही अच्छा top-level context बन सकता है, यही बात शानदार है
      मौजूदा requests को पुराने logic से स्वाभाविक रूप से handle करते हुए नई requests को नए logic से शुरू कराया जा सकता है, और अंत में पुराना logic garbage collect हो सकता है
    • यह सही है कि remote virtual machine में F code पहले से होना चाहिए, लेकिन code को remote virtual machine पर भेजा भी जा सकता है
      उदाहरण के लिए Elixir में Code.compile_string से module name और BEAM bytecode binary मिल सकती है। उस bytecode को दूसरी virtual machine पर भेजकर :rpc.call('node@remote_host', :code, :load_binary, [the_module_name, "filename_doesnt_really_matter", binary_code]) से remote virtual machine में load किया जा सकता है, और फिर spawn('node@remote_host', my_module, my_function, [args]) से उसे launch किया जा सकता है
    • quoted program remote machine पर run करने के लिए बनाया गया था, और remote machine उस नए program को deserialize करती है जिसे चलाना है
      यहाँ F एक variable है जो उस नए program को दर्शाता है जिसे serialize करके processes के बीच message के रूप में भेजा गया है, और इस मामले में वह network के ज़रिए भी भेजा जाता है

  • Joe ने Erlang में basic server लिखने का तरीका समझाने वाला एक lecture भी दिया था: https://gioorgi.com/2015/erlang-lesson1/
    मैंने इसे खुद लिखकर उतारा और थोड़ा और समझाया था; यह दिखाता है कि Erlang/Elixir जैसी asynchronous languages में दूसरी languages की तुलना में कैसी शक्ति होती है। अफ़सोस, आजकल इनका बहुत इस्तेमाल नहीं होता

  • हाल ही में मैं Julia में काफ़ी डूबा हुआ हूँ, और लगता है कि इसके distributed model ने Erlang के ideas काफ़ी हद तक उधार लिए हैं
    कई nodes पर जादुई ढंग से काम करने वाले ऐसे on-the-fly servers को Julia में भी काफ़ी आसानी से reproduce किया जा सकता है। पक्का नहीं कह सकता, लेकिन Julia के Distributed module ने Erlang से थोड़ा भी inspiration न लिया हो, ऐसा लगता नहीं
    मुझे Erlang सचमुच पसंद है और काश इसे ज़्यादा इस्तेमाल करने के मौके मिलते, लेकिन उसके concepts को दूसरे platforms में seep होते देखना भी अच्छा लगता है

    • Julia community में Erlang की error-reporting philosophy से निकले let it crash जैसे lessons समझाने में हम शायद एक ही side पर होंगे