multithreading - ما هو رد هاسكل على Node.js؟




haskell concurrency (5)

هل يمكن لـ Haskell تقديم بعض فوائد Node.js ، أي حل نظيف لتجنب حجب I / O دون اللجوء إلى برمجة متعددة الصفحات؟

نعم ، في الواقع يتم توحيد الأحداث والخيوط في هاسكل.

  • يمكنك البرنامج في خيوط خفيفة الوزن (مثل ملايين الخيوط على كمبيوتر محمول واحد).
  • أو؛ يمكنك البرنامج بأسلوب غير متزامن يعتمد على الحدث ، استنادًا إلى إعلام قابل للتطوير.

يتم تنفيذ سلاسل المحادثات فعليًا من حيث الأحداث ، ويتم تشغيلها عبر نوى متعددة ، مع ترحيل سلسلة محادثات سلسة ، مع أداء موثق وتطبيقات.

على سبيل المثال ل

المجموعات المتزامنة nbody على 32 النوى

في Haskell لديك كل الأحداث والخيوط ، وكما هو كل الأحداث تحت غطاء محرك السيارة.

اقرأ الورقة التي تصف التنفيذ.

أعتقد أن مجتمع Erlang ليس حسودًا من Node.js كما يفعل I / O غير المحظور أصلاً ولديه طرق لتوزيع النشر بسهولة على أكثر من معالج واحد (شيء لا يدمج حتى في Node.js). مزيد من التفاصيل على http://journal.dedasys.com/2010/04/29/erlang-vs-node-js و Node.js أو Erlang

ماذا عن هاسكل؟ هل يمكن لـ Haskell تقديم بعض فوائد Node.js ، أي حل نظيف لتجنب حجب I / O دون اللجوء إلى برمجة متعددة الصفحات؟

هناك العديد من الأشياء الجذابة مع Node.js

  1. أحداث: لا يوجد معالجة مؤشر ترابط ، يوفر للمبرمج فقط callbacks (كما في إطار Snap)
  2. يتم ضمان عمليات الرد في مؤشر ترابط واحد: لا يوجد شرط سباق ممكن.
  3. لطيفة وبسيطة API UNIX ودية. مكافأة: دعم HTTP ممتاز. DNS متاح أيضا.
  4. كل I / O بشكل افتراضي غير متزامن. هذا يجعل من السهل تجنب الأقفال. ومع ذلك ، فإن الكثير من معالجة وحدة المعالجة المركزية في معاودة الاتصال ستؤثر على الاتصالات الأخرى (في هذه الحالة ، يجب تقسيم المهمة إلى مهام فرعية أصغر وإعادة جدولة).
  5. نفس اللغة للجانب العميل والخادم. (لا أرى قيمة كبيرة في هذا ، على أية حال. jQuery و Node.js يشتركان في نموذج برمجة الحدث لكن الباقي مختلفان جدًا. لا أستطيع أن أرى كيف يمكن لمشاركة الشفرة بين الخادم والجانب العميل تكون مفيدة في الممارسة.)
  6. كل هذا تعبئتها في منتج واحد.

أحداث IMHO جيدة ، ولكن البرمجة عن طريق callbacks ليست كذلك.

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

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

هناك أطر قائمة على التسلسل مثل ocsigen (ocaml) على شاطئ البحر (smalltalk) WASH (تم إيقافها ، Haskell) و mflow (Haskell) التي تحل مشكلة إدارة الدولة مع الحفاظ على قابلية الملاحة و rEST-fulness. في إطار هذه الأطر ، يمكن للمبرمج التعبير عن الملاحة كتسلسل أمني حيث يرسل البرنامج الصفحات وينتظر الردود في خيط واحد ، والمتغيرات في نطاقها ويعمل زر العودة آليا. ينتج هذا بطبيعتها شفرة أقصر وأكثر أمانًا وأكثر قابلية للقراءة حيث يكون التنقل مرئيًا بوضوح للمبرمج. (تحذير عادل: أنا المطور من mflow)


أولاً ، لا أحمل وجهة نظرك بأن node.js تفعل الشيء الصحيح الذي يعرض جميع تلك الاستدعاءات. ينتهي بك الأمر كتابة البرنامج الخاص بك في CPS (نمط تمرير مستمر) وأعتقد أنه يجب أن يكون مهمة المترجم للقيام بهذا التحول.

أحداث: لا يوجد معالجة مؤشر ترابط ، يوفر للمبرمج فقط callbacks (كما في إطار Snap)

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

يتم ضمان عمليات الرد في مؤشر ترابط واحد: لا يوجد شرط سباق ممكن.

لا يزال بإمكانك الحصول على حالة سباق في node.js ، لكن الأمر أكثر صعوبة.

كل طلب في موضوعه الخاص. عند كتابة التعليمات البرمجية التي لها علاقة مع مؤشرات ترابط أخرى ، فإنه من السهل جدًا جعلها آمنة باستخدام primase at haskell's.

لطيفة وبسيطة API UNIX ودية. مكافأة: دعم HTTP ممتاز. DNS متاح أيضا.

نلقي نظرة في hackage ونرى بنفسك.

كل I / O بشكل افتراضي غير متزامن (وهذا يمكن أن يكون مزعج في بعض الأحيان ، على الرغم من). هذا يجعل من السهل تجنب الأقفال. ومع ذلك ، فإن الكثير من معالجة وحدة المعالجة المركزية في معاودة الاتصال ستؤثر على الاتصالات الأخرى (في هذه الحالة ، يجب تقسيم المهمة إلى مهام فرعية أصغر وإعادة جدولة).

ليس لديك مثل هذه المشاكل ، سيوزع ghc عملك بين خيوط نظام التشغيل الحقيقية.

نفس اللغة للجانب العميل والخادم. (لا أرى قيمة كبيرة في هذا ، إلا أن JQuery و Node.js يشتركان في نموذج برمجة الحدث ، لكن الباقي مختلف تمامًا. لا أستطيع أن أرى كيف يمكن لتشفير الشفرة بين الخادم والجانب العميل تكون مفيدة في الممارسة.)

هاسكل لا يمكنه الفوز هنا ... صحيح؟ فكر مرة أخرى ، http://www.haskell.org/haskellwiki/Haskell_in_web_browser .

كل هذا تعبئتها في منتج واحد.

تحميل ghc ، أطلق النار على عصابة. هناك حزمة لكل حاجة.


السؤال مثير للسخرية لأن (1) Haskell قد حل بالفعل هذه المسألة بطريقة أفضل و 2) تقريبا بنفس الطريقة التي بها Erlang. هنا هو معيار مقابل العقدة: yesodweb.com/blog/2011/03/…

إعطاء Haskell 4 النوى ويمكن أن تفعل طلبات 100K (بسيط) في الثانية الواحدة في تطبيق واحد. لا يمكن للعقدة القيام بالكثير ، ولا يمكنها توسيع نطاق تطبيق واحد عبر النوى. وليس لديك لفعل أي شيء لجني هذا لأن وقت تشغيل Haskell غير مقيد. اللغة الأخرى (الشائعة نسبياً) فقط التي تحتوي على IO غير محجوب مضمنة في وقت التشغيل هي Erlang.


حسنًا ، بعد أن شاهدت القليل من youtube.com/watch?v=F6k8lTrAE2g الذي أشار إليه @ gawi ، يمكنني أن أقول أكثر قليلاً عن كيفية مقارنة هاسكل بـ node.js. في العرض التقديمي ، يشرح ريان بعض فوائد الخيوط الخضراء ، لكنه يستمر في القول إنه لا يجد نقص تجريد الخيوط في كونه سلبيًا. أنا أختلف مع موقفه ، لا سيما في سياق هاسكل: أعتقد أن التجريدات التي توفرها الخيوط ضرورية لجعل كود الخادم أسهل في الحصول عليه ، وأكثر قوة. خاصه:

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

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

  • التزامن ليس من الصعب في هاسكل ، لأن معظم التعليمات البرمجية هي نقية وهكذا آمن الصفحات من قبل البناء. هناك بدايات اتصال بسيطة. من الأصعب بكثير أن تطلق النار على نفسك في القدم مع التزامن في هاسكل من لغة ذات آثار جانبية غير مقيدة.





node.js