خلط Erlang و Haskell

Question

إذا كنت قد اشتريت في نموذج البرمجة الوظيفية ، فمن المحتمل أن تحب كل من Erlang و Haskell. كلاهما لهما نوى وظيفية بحتة وغيرها من الخير مثل الخيوط الخفيفة التي تجعلهما مناسبًا لعالم متعدد الأوساخ. ولكن هناك بعض الاختلافات أيضا.

Erlang هي لغة مثبتة تجاريًا تتحمل الأخطاء مع نموذج توزيع ناضج. لديها ميزة فريدة من نوعها على ما يبدو في قدرتها على ترقية نسختها في وقت التشغيل عبر تحميل الرمز الساخن. (طريقة رائعة!)

Haskell ، على الجانب الآخر ، لديه نظام النوع الأكثر تطوراً لأي لغة سائدة. (حيث أعرّف "التيار الرئيسي" على أن تكون أي لغة تحتوي على كتاب O'Reilly المنشور ، لذا فإن Haskell Countts.) يبدو أدائه المباشر المفرد المتصور متفوقًا على Erlang's وخيوطه الخفيفة ، تبدو أخف أيضًا.

أحاول تجميع منصة تطوير بقية حياتي الترميز وكان يتساءل عما إذا كان من الممكن خلط Erlang و Haskell لتحقيق أفضل منصة سلالة. يحتوي هذا السؤال على جزأين:

1. أرغب في استخدام Erlang كنوع من MPI المتسامح مع الأخطاء لإلتصاق مثيلات وقت تشغيل GHC معًا. سيكون هناك عملية Erlang واحدة لكل وقت تشغيل GHC. إذا "حدث المستحيل" وتوفي وقت تشغيل GHC ، فإن عملية إرلانج ستكتشف ذلك بطريقة أو بأخرى. ستستمر ميزات تحميل الرمز الساخن والتوزيع في Erlang في العمل. يمكن تكوين وقت تشغيل GHC لاستخدام نواة واحدة فقط ، أو جميع النوى على الجهاز المحلي ، أو أي مزيج بينهما. بمجرد كتابة مكتبة Erlang ، يجب أن تكون بقية رمز مستوى Erlang محضًا وإنشاء تلقائيًا على أساس كل تطبيق. (ربما بواسطة Haskell DSL على سبيل المثال.) كيف يمكن للمرء أن يحقق بعض هذه الأشياء على الأقل؟
2. أود أن يكون Erlang و Haskell قادرين على مشاركة نفس جامع Garabage. (هذه فكرة أخرى أكثر من 1.) اللغات التي تعمل على JVM و CLR تحقق كتلة أكبر من خلال مشاركة وقت التشغيل. أدرك أن هناك قيودًا تقنية لتشغيل Erlang (تحميل الكود الساخن) و Haskell (تعدد الأشكال المرتفع) على JVM أو CLR. ولكن ماذا عن تفكيك جامع القمامة فقط؟ (نوع من بداية وقت التشغيل للغات الوظيفية.) من الواضح أن التخصيص يجب أن يكون سريعًا حقًا ، لذلك ربما يجب أن يكون هذا الشيء مرتبطًا بشكل ثابت. ويجب أن يكون هناك بعض الميكانيكية لتمييز الكومة القابلة للتغيير عن الكومة غير القابلة للتغيير ( حدوث كسول الكتابة مرة واحدة الذاكرة) لأن GHC تحتاج إلى هذا. هل سيكون من الممكن تعديل كل من Hipe و GHC حتى يتمكن جامعو القمامة من مشاركة كومة؟

يرجى الإجابة بأي تجارب (إيجابية أو سلبية) ، الأفكار أو الاقتراحات. في الواقع ، أي ردود فعل (أقل من سوء المعاملة المستقيمة!) موضع ترحيب.

تحديث

شكرًا على جميع الردود الأربعة حتى الآن - علمني كل منها شيئًا مفيدًا على الأقل لم أكن أعرفه.

بخصوص بقية ترميز الحياة الشيء - لقد قمت بتضمينه قليلاً لسان في الخد لإثارة النقاش ، لكنه صحيح بالفعل. هناك مشروع يدور في ذهني أعتزم العمل عليه حتى أموت ، ويحتاج إلى منصة مستقرة.

في النظام الأساسي الذي اقترحته أعلاه ، سأكتب Haskell فقط ، حيث سيتم إنشاء Erlang Boilerplate تلقائيًا. إذن ما هي المدة التي ستستمر فيها هاسكل؟ حسنًا ، لا يزال Lisp معنا ولا يبدو أنه يذهب بعيدًا في أي وقت قريب. Haskell هو BSD3 مفتوح المصدر وحقق كتلة حرجة. إذا كانت البرمجة نفسها لا تزال موجودة منذ 50 عامًا ، فأتوقع أن يظل Haskell ، أو بعض التطور المستمر لـ Haskell ، هنا.

تحديث 2 ردا على منشور Rvirding

المتفق عليها - قد لا يكون تنفيذ الجهاز الافتراضي العالمي "Erskell/Haslang" مستحيلًا تمامًا ، لكنه سيكون من الصعب للغاية بالفعل بالفعل. مشاركة مستوى جامع القمامة فقط كشيء مثل VM ، بينما لا يزال صعبة, ، يبدو ترتيبًا أقل صعوبة بالنسبة لي. في نموذج جمع القمامة ، يجب أن يكون لدى اللغات الوظيفية الكثير من العوامل المشتركة - عدم وجود بيانات ثابتة (بما في ذلك thunks) ومتطلبات التخصيص السريع للغاية. لذا فإن حقيقة أن القواسم المشتركة يتم تجميعها بإحكام مع VMs المتجانسة تبدو غريبًا.

VMs تساعد على تحقيق الكتلة الحرجة. انظر فقط إلى كيفية خلع اللغات الوظيفية "lite" مثل F# و Scala. قد لا يكون لدى Scala التسامح المطلق في Erlang ، ولكنه يوفر طريق الهروب للعديد من الأشخاص الذين يرتبطون بـ JVM.

في حين أن وجود كومة واحدة تجعل رسالة تمر بسرعة كبيرة ، إلا أنها تقدم عددًا من المشكلات الأخرى ، إلا أن القيام بـ GC يصبح أكثر صعوبة لأنها يجب أن تكون تفاعلية وغير متداخلة على المستوى العالمي حتى لا تتمكن نموذج كومة العملية.

بالتأكيد ، هذا منطقي تمامًا بالنسبة لي. يبدو أن الأشخاص الأذكياء للغاية في فريق تطوير GHC يحاولون حل جزء من المشكلة مع GC "إيقاف العالم" الموازي.

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

(من الواضح أن "توقف العالم" لن يطير إلى الجنرال إرلانج بالنظر إلى حالة الاستخدام الرئيسية.) ولكن حتى في حالات الاستخدام التي تكون فيها "توقف العالم" على ما يرام ، لا تبدو سرعاتها عالمية. لذلك أنا أتفق معك ، فمن غير المرجح أن يكون هناك أفضل GC ، وهذا هو السبب في تحديده في الجزء 1. من سؤالي

يمكن تكوين وقت تشغيل GHC لاستخدام نواة واحدة فقط ، أو جميع النوى على الجهاز المحلي ، أو أي مزيج بينهما.

وبهذه الطريقة ، بالنسبة لحالة الاستخدام المحددة ، يمكنني ، بعد القياس ، اختيار طريق Erlang ، وتشغيل وقت تشغيل GHC واحد (مع GC SingleTherved) بالإضافة .

بدلاً من ذلك ، على جهاز معالج مزدوج مع 4 نوى لكل معالج مع عرض النطاق الترددي الذاكرة الجيد على المعالج ، قد يشير القياس إلى أنني أقوم بتشغيل وقت تشغيل GHC واحد (مع GC متوازي) بالإضافة إلى عملية Erlang واحدة لكل معالج.

في كلتا الحالتين ، إذا تمكنت Erlang و GHC من مشاركة كومة ، فمن المحتمل أن تكون المشاركة مرتبطة بخيط نظام OS واحد يعمل على قلب واحد بطريقة أو بأخرى. (أنا أخرج من عملي هنا ، وهذا هو السبب في أنني طرحت السؤال.)

لديّ أيضًا جدول أعمال آخر - قياس اللغات الوظيفية بشكل مستقل عن GC. في كثير من الأحيان قرأت نتائج معايير OCAML V GHC V ERLANG V ... وأتساءل عن مدى الخلط بين النتائج المختلفة. ماذا لو أن اختيار GC يمكن أن يكون متعامدًا لاختيار اللغة الوظيفية؟ ما مدى تكلفة GC على أي حال؟ شاهد منشور مدونة Devil Advocates

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

من قبل صديقي Lisp John Fremlin ، الذي لديه ، بشكل ساحر ، بالنظر إلى لقب منشوره "مجموعة القمامة الآلية هي القمامة". عندما يدعي جون أن GC بطيئة ولم يسبق له مثيل ، أود أن أكون قادرًا على مواجهة بعض الأرقام.

Answer 1

يهتم الكثير من الناس من Haskell و Erlang بالنموذج الذي يشرف عليه Erlang التوزيع ، بينما يقوم Haskell بتشغيل عقد الذاكرة المشتركة بالتوازي مع كل الأرقام التي تتجول/منطق.

بداية هذا هو مكتبة هاسكل إيرلانج: http://hackage.haskell.org/package/erlang

ولدينا جهود مماثلة في Ruby Land ، عبر الغطرسة: http://github.com/mwotton/hubris/tree/master

والسؤال الآن هو العثور على شخص ما للدفع فعليًا عبر Erlang / Haskell interop لمعرفة القضايا الصعبة.

Answer 2

سيكون لديك وقت مثير للاهتمام في خلط GC بين Haskell و Erlang. يستخدم Erlang كومة لكل عملية ونسخ البيانات بين العمليات-حيث أن Haskell لا يحتوي حتى على مفهوم للعمليات ، لست متأكدًا من كيفية تعيين GC "العالمي" بين الاثنين. علاوة على ذلك ، بالنسبة لأفضل أداء ، يستخدم Erlang مجموعة متنوعة من المخصصين ، ولكل منها سلوكيات تم تعديلها قليلاً والتي أنا متأكد من أنها ستؤثر على نظام GC الفرعي.

كما هو الحال مع كل الأشياء في البرمجيات ، يأتي التجريد بتكلفة. في هذه الحالة ، أظن أنه يتعين عليك تقديم العديد من الطبقات للحصول على كلتا اللغتين على عدم التوافق في المقاومة التي تنتهي بها الأمر مع VM شائع غير مؤلف (أو مفيد).

خلاصة القول - احتضان الفرق! هناك مزايا ضخمة لعدم تشغيل كل شيء في نفس العملية ، وخاصة من وجهة نظر الموثوقية. أيضًا ، أعتقد أنه من السذاجة بعض الشيء أن تتوقع أن تدوم لغة واحدة/VM لبقية حياتك (ما لم تكن تخطط على. مشروع واحد). إن تطوير البرمجيات يدور حول خفة الحركة العقلية والاستعداد لاستخدام أفضل الأدوات المتاحة لبناء رمز سريع وموثوق.

Answer 3

على الرغم من أن هذا موضوع قديم ، إذا كان القراء لا يزالون مهتمين ، فهذا يستحق إلقاء نظرة عليه سحابة هاسكل, ، الذي يجلب التزامن على نمط إرلانج وتوزيعه على مستقر GHC.

القادم موزع العمليات تضيف المكتبة دعمًا للبنيات OTP-esque مثل Gen_servers وأشجار الإشراف والعديد من التجريدات الأخرى "النكهة" التي تم استعارة من Erlang/OTP.

Answer 4

1. يمكنك استخدام عملية OTP Gen_Supervisor لمراقبة مثيلات Haskell التي تفرخها باستخدام Open_Port (). اعتمادًا على كيفية خروج "المنفذ" ، ستتمكن بعد ذلك من إعادة تشغيله أو تحديد أنه توقف عن قصد وترك عملية Erlang المقابلة تموت أيضًا.

2. Fugheddaboudit. حتى VMs المستقلة عن اللغة التي تتحدث عنها لديها مشكلة مع البيانات التي تم تمريرها بين اللغات في بعض الأحيان. يجب عليك فقط تخصيص البيانات بين الاثنين بطريقة ما: قاعدة البيانات ، XML-RPC ، شيء من هذا القبيل.

بالمناسبة ، ربما تكون فكرة منصة واحدة لبقية حياتك غير عملية أيضًا. تحوسب التكنولوجيا وتغيير الأزياء في كثير من الأحيان لتتوقع أنه يمكنك الاستمرار في استخدام لغة واحدة فقط إلى الأبد. يشير سؤالك بالذات: لا توجد لغة واحدة تفعل كل ما نتمناه ، حتى اليوم.

Answer 5

كما ذكر Dizzyd في تعليقه ، لا يتم نسخ جميع البيانات في الرسائل ، توجد ثنائيات كبيرة خارج أكوام العملية ولا يتم نسخها.

من المؤكد أن استخدام بنية ذاكرة مختلفة لتجنب وجود أكوام منفصلة لكل عملية عملية ، وقد تم القيام به في عدد من التطبيقات السابقة. في حين أن امتلاك كومة واحدة تجعل رسالة مرحلة جداً تقدم سريعًا عددًا من المشكلات الأخرى ، وذلك بشكل أساسي أن القيام GC يصبح أكثر صعوبة حيث يجب أن يكون تفاعليًا وغير متداخل عالميًا ، لذا لا يمكنك استخدام نفس الخوارزميات الأكثر بساطة كنموذج كومة لكل عملية.

طالما نستخدمها ، لا توجد هياكل بيانات غير قابلة للتغيير ، فلا توجد مشكلة مع المتانة والسلامة. يعد تحديد نماذج الذاكرة ونماذج GC لاستخدامه بمقايضة كبيرة ، وللأسف هناك أفضل نموذج عالميًا.

في حين أن هاسكل وإرلانغ كلاهما لغات وظيفية ، إلا أنهما في كثير من النواحي لغات مختلفة للغاية ولديهما تطبيقات مختلفة تمامًا. من الصعب التوصل إلى آلة "Erskell" (أو Haslang) والتي يمكن أن تتعامل مع كلتا اللغتين بكفاءة. أنا شخصياً أعتقد أنه من الأفضل أن تبقيهم منفصلين والتأكد من أن لديك واجهة جيدة حقًا بينهما.

Answer 6

يدعم CLR تحسين مكالمة الذيل مع صريح tail OPCODE (كما هو مستخدم من قبل F#) ، والتي لا تحتوي JVM (حتى الآن) على ما يعادلها ، مما يحد من تنفيذ مثل هذا النمط من اللغة. استخدام منفصلة AppDomainS يسمح لـ CLR برمز SWAP الساخن (انظر على سبيل المثال منشور المدونة هذا إظهار كيف يمكن القيام بذلك).

مع عمل Simon Peyton Jones في أسفل الممر من Don Syme وفريق F# في Microsoft Research ، سيكون من خيبة أمل كبيرة إذا لم نر في نهاية المطاف Ironhaskell مع نوع من الوضع الرسمي. سيكون Ironerlang مشروعًا مثيرًا للاهتمام-من المحتمل أن يكون أكبر عمل هو نقل جدولة الخيوط الخضراء دون الحصول على وزن ثقيل مثل محرك Windows Workflow ، أو الاضطرار إلى تشغيل شعاع VM على رأس CLR.