49

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

एरलांग परिपक्व वितरण मॉडल के साथ व्यावसायिक रूप से सिद्ध गलती-सहनशील भाषा है। हॉट कोड लोडिंग के माध्यम से रनटाइम पर अपने संस्करण को अपग्रेड करने की इसकी क्षमता में इसकी एक अनूठी विशेषता है। (रास्ता शांत!)

दूसरी ओर, हास्केल, किसी भी मुख्यधारा की भाषा का सबसे परिष्कृत प्रकार प्रणाली है। (जहां मैं 'मुख्यधारा' को किसी भी भाषा के रूप में परिभाषित करता हूं जिसमें प्रकाशित ओ'रेली पुस्तक है, इसलिए हास्केल की गणना होती है।) इसकी सीधी रेखा एकल प्रदर्शन एरलांग से बेहतर दिखता है और इसके हल्के धागे भी हल्के दिखते हैं।

मैं के लिए मेरे विकास कोड के लिए एक विकास मंच को एक साथ रखने की कोशिश कर रहा हूं और यह सोच रहा था कि नस्ल और हास्केल को सर्वोत्तम नस्ल प्लेटफॉर्म प्राप्त करने के लिए मिश्रण करना संभव था या नहीं। इस प्रश्न में दो भाग हैं:

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

कृपया किसी भी अनुभव (सकारात्मक या नकारात्मक), विचारों या सुझावों के साथ उत्तर दें। वास्तव में, कोई प्रतिक्रिया (सीधे दुरुपयोग से कम!) का स्वागत है।

अद्यतन

तारीख करने के लिए सभी 4 उत्तर के लिए धन्यवाद - प्रत्येक मुझे कम से कम एक उपयोगी बात यह है कि मुझे नहीं पता था सिखाया।

के बारे में 0 कोडिंग जीवन चीज - मैंने इसे बहस में थोड़ा सा जीभ शामिल किया ताकि बहस फैलाने के लिए, लेकिन यह वास्तव में सच है। एक परियोजना है जो मुझे याद है कि मैं मरने तक काम करना चाहता हूं, और इसे एक स्थिर मंच की आवश्यकता है।

प्लेटफ़ॉर्म में मैंने ऊपर प्रस्तावित किया है, मैं केवल हास्केल लिखूंगा, क्योंकि बॉयलरप्लेट एरलांग स्वचालित रूप से जेनरेट हो जाएगा। तो हास्केल कितने समय तक चलेगा? खैर लिस्प अभी भी हमारे साथ है और ऐसा नहीं लगता कि यह जल्द ही दूर जा रहा है। हास्केल बीएसडी 3 ओपन सोर्स है और उसने महत्वपूर्ण द्रव्यमान हासिल किया है।यदि प्रोग्रामिंग स्वयं 50 साल के आसपास भी है, तो मैं हास्केल, या हास्केल के कुछ निरंतर विकास की उम्मीद करता हूं, अभी भी यहां होगा।

अद्यतन 2जवाब में की पोस्ट

सहमत rvirding करने के लिए - एक पूरा "Erskell/Haslang" सार्वभौमिक आभासी मशीन को लागू करने बिल्कुल असंभव नहीं हो सकता है, लेकिन यह निश्चित वास्तव में बहुत मुश्किल होगा। वीएम की तरह कुछ कचरा कलेक्टर स्तर साझा करना, जबकि अभी भी कठिन, हालांकि मेरे लिए कम परिमाण का क्रम लगता है। कचरा संग्रहण मॉडल में, कार्यात्मक भाषाओं में बहुत आम होना चाहिए - अपरिवर्तनीय डेटा (थंक्स समेत) की अनियमितता और बहुत तेज आवंटन की आवश्यकता। तो तथ्य यह है कि समानता को मोनोलिथिक वीएम के साथ कसकर बंडल किया जाता है, यह अजीब लगता है।

वीएम महत्वपूर्ण द्रव्यमान प्राप्त करने में मदद करते हैं। बस देखें कि एफ # और स्कैला जैसी 'लाइट' कार्यात्मक भाषाओं को कैसे हटाया गया है। स्कैला में एरलांग की पूर्ण गलती सहनशीलता नहीं हो सकती है, लेकिन यह JVM से जुड़े बहुत से लोगों के लिए एक बचने का मार्ग प्रदान करता है।

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

बिल्कुल, यह मेरे लिए सही मायने रखता है। जीएचसी विकास दल के बहुत ही स्मार्ट लोग समानांतर "दुनिया को रोकें" जीसी के साथ समस्या का हिस्सा हल करने की कोशिश कर रहे हैं।

http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf

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

GHC क्रम उपयोग सिर्फ एक कोर करने के लिए कॉन्फ़िगर किया जा सकता है, या स्थानीय मशीन पर सभी कोर, या में किसी भी संयोजन के बीच।

कि रास्ते में, किसी दिए गए उपयोग के मामले के लिए, मैं, बेंच मार्किंग के बाद, Erlang रास्ते जाने के लिए चुन सकते हैं, और एक GHC क्रम (एक singlethreaded जीसी के साथ) के साथ साथ मूल प्रति एक Erlang प्रक्रिया चलाने के लिए और Erlang नकल करते हैं अच्छे इलाके के लिए कोर के बीच स्मृति।

वैकल्पिक रूप से, प्रोसेसर पर अच्छी मेमोरी बैंडविड्थ के साथ 4 कोर प्रति प्रोसेसर के साथ दोहरी प्रोसेसर मशीन पर, बेंचमार्किंग का सुझाव हो सकता है कि मैं एक जीएचसी रनटाइम (समानांतर जीसी के साथ) और प्रति प्रोसेसर एक एरलंग प्रक्रिया चलाता हूं।

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

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

http://john.freml.in/garbage-collection-harmful

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

+0

इसी तरह की प्रेरणा के साथ, अगले दशक के लिए बसने के लिए "सही भाषा मिश्रण" के लिए मेरा निष्कर्ष या जंग शामिल था। शायद मेरे एम्बेडेड सिस्टम पृष्ठभूमि की वजह से। तो मेरा सपना टीम मिश्रण होगा: एरलांग | योग्य प्रतिस्थापन + हास्केल + जंग। – BitTickler

उत्तर

28

बहुत सारे हास्केल और एरलांग लोग उस मॉडल में रूचि रखते हैं जहां एरलांग वितरण का पर्यवेक्षण करता है, जबकि हास्केल सभी संख्या क्रंचिंग/तर्क के समानांतर में साझा मेमोरी नोड चलाता है।

एक इस दिशा में शुरू Haskell-erlang पुस्तकालय है: http://hackage.haskell.org/package/erlang

और हम अभिमान के माध्यम से रूबी देश में समान प्रयासों,: http://github.com/mwotton/Hubris/tree/master

सवाल अब किसी को मिल रहा है वास्तव में Erlang के माध्यम से पुश करने के लिए मुश्किल मुद्दों को जानने के लिए/हास्केल इंटरऑप।

+0

धन्यवाद! यह अब तक का सबसे ज्यादा सूचित उत्तर प्रतीत होता है। तो ऐसा लगता है कि मैं 1 में क्या पूछ रहा हूं। कम से कम इतना है कि बहुत से लोग पहले से ही क्या चाहते हैं। इससे पता चलता है कि यह एक समझदार दिशा है, जो जानना बहुत अच्छा है। मैं न तो हैकेल-एरलांग और न ही हबिस ... के बारे में जानता था। –

+2

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

+0

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

4
  1. आप OTP का gen_supervisor प्रक्रिया का उपयोग हास्केल उदाहरणों है कि आप() open_port साथ अंडे नजर रखने के लिए कर सकता है। "पोर्ट" से बाहर निकलने के तरीके के आधार पर, आप फिर इसे पुनरारंभ करने में सक्षम होंगे या निर्णय लेंगे कि यह उद्देश्य पर बंद हो गया है और संबंधित एरलांग प्रक्रिया भी मरने देगी।

  2. फुगड़ेडबौडिट। यहां तक ​​कि इन भाषा-स्वतंत्र वीएम जिन्हें आप बोलते हैं, कभी-कभी भाषाओं के बीच पारित डेटा के साथ परेशानी होती है। आपको किसी भी तरह से डेटा को क्रमबद्ध करना चाहिए: डेटाबेस, एक्सएमएल-आरपीसी, ऐसा कुछ।

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

+0

उत्तर के लिए धन्यवाद, विशेष रूप से तकनीकी विवरण 1. आपके उत्तर 2। मुझे उम्मीद है कि ज्यादातर लोग कहेंगे - यह कोडिंग लाइफ प्लेटफॉर्म के बाकी हिस्सों के बारे में एक और लक्ष्य है - मैं 45 वर्ष का हूं StackOverlow पर कुछ से कम हो सकता है। लेकिन आपका मुद्दा अच्छी तरह से बनाया गया है। फैशन बदलते हैं - लेकिन सामान्य रूप से कार्यात्मक प्रोग्रामिंग जैसी चीजें और संदेश गुजरने से विचार लंबे समय तक रहते हैं। तो वास्तव में मैं एक मंच की तलाश में हूं जिसे मैं विकसित कर सकता हूं। –

+1

मेरे अनुमान से, आपके पास सेवानिवृत्त होने के योग्य होने से पहले आपके पास दो फैशन युग शेष हैं। :) –

+0

अनुमान के लिए धन्यवाद ;-) –

2

सीएलआर एक स्पष्ट tail ऑपोड (जैसा कि एफ # द्वारा उपयोग किया जाता है) के साथ पूंछ कॉल अनुकूलन का समर्थन करता है, जो कि जेवीएम (अभी तक) समकक्ष नहीं है, जो भाषा की ऐसी शैली के कार्यान्वयन को सीमित करता है। अलग AppDomain एस का उपयोग सीएलआर को हॉट-स्वैप कोड की अनुमति देता है (उदाहरण के लिए this blog post दिखाता है कि यह कैसे किया जा सकता है)।

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

+0

सीएलआर/जेवीएम पर तकनीकी प्रतिक्रिया के लिए धन्यवाद। आईआईआरसी सही ढंग से, एक एसपीजे साक्षात्कार था जहां उन्होंने कहा कि सीएलआर के पास जेवीएम की तुलना में कार्यात्मक प्रोग्रामिंग के लिए थोड़ा अधिक समर्थन था, लेकिन मुझे नहीं पता था कि क्यों। अब मुझे पता है कि पूंछ opcode का अस्तित्व है। –

+0

AppDomains के लिंक के संबंध में, यह निश्चित रूप से दिलचस्प है, और एर्लांग की कुछ विशेषताओं का अनुकरण करने की अनुमति दे सकता है। हालांकि, Erlang की विश्वसनीयता के सिद्ध स्तर को हासिल करना मुश्किल होगा। –

+0

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

4

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

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

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

+0

एरलंग प्रति प्रक्रिया ढेर के बारे में जानकारी के साथ आपके उत्तर के लिए बहुत बहुत धन्यवाद। खैर मुझे लगता है कि मैं जीएचसी रनटाइम के 1 उदाहरण के साथ 1 एरलांग प्रक्रिया से ढेर साझा करूंगा। फिर मेरे quesion 1. के लिए, मैं इसे कॉपी करने के बिना Erlang और Haskell के बीच अपरिवर्तनीय डेटा पारित कर सकता है। –

+0

मुझे याद है कि एरलांग हमेशा प्रक्रियाओं के बीच अपरिवर्तनीय डेटा कॉपी नहीं करता था। क्या आपको इसका कोई ज्ञान है? –

+0

मैं आपके साथ अमूर्त लागत की लागत के बारे में सहमत हूं। हालांकि, ऐसा लगता है कि ज्यादातर abstractions पर्याप्त सार नहीं हैं - वे वास्तव में रिसाव। मुझे लगता है कि यह अच्छा अवशोषण तलाशने के लिए एक सार्थक खोज है - बहुत मुश्किल है, लेकिन कम से कम किसी के लिए प्रयास नहीं कर रहा है। –

4

जैसा कि उनकी टिप्पणी में वर्णित है, संदेश में सभी डेटा कॉपी नहीं किए गए हैं, प्रक्रिया के ढेर के बाहर बड़ी बाइनरी मौजूद हैं और कॉपी नहीं की गई हैं।

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

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

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

+0

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

5

हालांकि यह एक बहुत पुराना धागा है, अगर पाठकों को अभी भी रुचि है तो Cloud Haskell पर एक नज़र डालने लायक है, जो एआरएलएंग शैली समेकन और जीएचसी स्थिरता में वितरण लाता है।

आगामी distributed-process-platform लाइब्रेरी ओटीपी-एस्क्यू संरचनाओं जैसे जेन_सेवर, पर्यवेक्षण पेड़ और कई अन्य "हैकेल स्वाद" अवशोषणों के लिए समर्थन प्रदान करता है जो एरलांग/ओटीपी द्वारा उधार और प्रेरित होते हैं।