لغات البرمجة

المحتويات:

• الملخص
  • المسألة
  • القرار
  • الحالة
• التفاصيل
  • الافتراضات
  • القيود
  • المواقف
  • الحجة
  • التبعات
• ذو صلة
  • قرارات ذات صلة
  • متطلبات ذات صلة
  • نواتج ذات صلة
  • مبادئ ذات صلة
• ملاحظات

الملخص

المسألة

نحتاج إلى اختيار لغات برمجة لبرمجياتنا. ولدينا حاجتان رئيسيتان: لغة برمجة للواجهة الأمامية مناسبة لتطبيقات الويب، ولغة برمجة للواجهة الخلفية مناسبة لتطبيقات الخوادم.

القرار

نختار TypeScript للواجهة الأمامية.

ونختار Rust للواجهة الخلفية.

الحالة

تم القرار. ونحن منفتحون على بدائل جديدة كلما ظهرت.

التفاصيل

الافتراضات

تطبيقات الواجهة الأمامية نموذجية:

• مستخدمون وتفاعلات نموذجية

• متصفحات وأنظمة نموذجية

• تطويرات وعمليات نشر نموذجية

من المرجح أن تتطور تطبيقات الواجهة الأمامية بسرعة:

• نريد ضمان تطويرات وعمليات نشر وتكرارات سريعة وسهلة وما إلى ذلك.

• نقدّر القدرة على البرهنة، مثل أمان الأنواع، ولا مانع لدينا من بذل مزيد من العمل لتحقيقها.

• لا نحتاج إلى توافق مع الأنظمة القديمة.

تطبيقات الواجهة الخلفية أعلى من المعتاد في متطلباتها:

• أهداف جودة أعلى من المعتاد، خصوصًا القدرة على البرهنة والموثوقية والأمان وغيرها.

• أهداف أعلى من المعتاد في الزمن شبه الحقيقي، أي أننا لا نريد توقفات ناتجة عن جمع النفايات في الآلة الافتراضية.

• أهداف أعلى من المعتاد في البرمجة الوظيفية، خصوصًا للتوازي والمعالجة متعددة الأنوية وسلامة الذاكرة.

نقبل سرعات ترجمة أقل مقابل الأمان وقت الترجمة وسرعات وقت التشغيل.

القيود

لدينا قيد قوي على اللغات التي يمكن استخدامها مع خدمات الدوال لدى مزودي السحابة الرئيسيين، مثل Amazon Lambda.

المواقف

نظرنا في هذه اللغات:

• C

• C++

• Clojure

• Elixir

• Erlang

• Elm

• Flow

• Go

• Haskell

• Java

• JavaScript

• Kotlin

• Python

• Ruby

• Rust

• TypeScript

الحجة

ملخص لكل لغة:

• C: مرفوضة بسبب ضعف الأمان؛ تستطيع Rust فعل كل شيء تقريبًا على نحو أفضل.

• C++: مرفوضة لأنها فوضى؛ تستطيع Rust فعل كل شيء تقريبًا على نحو أفضل.

• Clojure: نمذجة ممتازة؛ أفضل تقريب لـLisp؛ بيئة تشغيل رائعة على JVM.

• Elixir: بيئة تشغيل ممتازة تشمل سهولة النشر والتزامن؛ تجربة مطور ممتازة؛ نظام بيئي صغير نسبيًا.

• Erlang: بيئة تشغيل ممتازة تشمل سهولة النشر والتزامن؛ تجربة مطور صعبة؛ نظام بيئي صغير نسبيًا.

• Elm: تبدو واعدة جدًا؛ تنشر IBM دراسات حالة كبيرة بنتائج جيدة؛ نظام بيئي أصغر.

• Flow: تحسين مثير للاهتمام على JavaScript؛ غير أن المطورين يبتعدون عنها.

• Go: تجربة مطور ممتازة؛ تزامن ممتاز؛ لكن لها سجلًا من القرارات السيئة التي تشلّ اللغة.

• Haskell: أفضل لغة وظيفية؛ مجتمع مطورين أصغر؛ لم تحقق نجاحات إنتاجية منشورة كافية.

• Java: بيئة تشغيل ممتازة؛ نظام بيئي ممتاز؛ تجربة مطور دون المتوسط.

• JavaScript: أشهر لغة على الإطلاق؛ أوسع نظام بيئي.

• Kotlin: تصحح كثيرًا من عيوب Java؛ دعم ممتاز من JetBrains؛ حالات منشورة جيدة للانتقال من Java إلى Kotlin.

• Python: أشهر لغة لإدارة الأنظمة؛ أدوات تحليلات رائعة؛ أطر ويب جيدة؛ لكن Google تخلّت عنها لصالح Go.

• Ruby: أفضل تجربة مطور على الإطلاق؛ أفضل أطر الويب؛ ألطف مجتمع؛ لكنها بطيئة جدًا؛ ويصعب تغليفها نوعًا ما.

• Rust: أفضل لغة جديدة؛ تركيز على صفر تجريد؛ تركيز على التزامن؛ غير أن نظامها البيئي صغير نسبيًا؛ ولها حدود متعمدة على بعض أنواع تسريعات المترجم، مثلًا يجب أن يكون الوصول المباشر إلى الذاكرة غير آمن (unsafe) صراحةً.

• TypeScript: تضيف أنواعًا إلى JavaScript؛ مترجم تحويلي ممتاز؛ تركيز متنامٍ للمطورين على الانتقال من JavaScript إلى TypeScript؛ دعم قوي من Microsoft.

قررنا أن للآلات الافتراضية مجموعة مفاضلات لا نحتاج إليها الآن، مثل التعقيد الإضافي الذي يوفر قدرات وقت التشغيل.

ونعتقد أن قرارنا المحوري تحركه شاغلان عابران:

• لأسرع سرعة تشغيل وأضيق وصول إلى النظام، كنا سنختار JavaScript وC.

• ولسرعة تشغيل قريبة من الأسرع ووصول إلى النظام قريب من الأضيق، نختار TypeScript وRust.

والذكر الحسن لغات الآلات الافتراضية وأطر الويب التي كنا سنختارها لو أردنا لغة ذات آلة افتراضية:

• Clojure وLuminus

• Java وSpring

• Elixir وPhoenix

التبعات

سيحتاج مطورو الواجهة الأمامية إلى تعلّم TypeScript. ومن المرجح أن يكون منحنى التعلم سهلًا إذا كانت خبرة المطور الأساسية في استخدام JavaScript.

وسيحتاج مطورو الواجهة الخلفية إلى تعلّم Rust. ومن المرجح أن يكون منحنى التعلم متوسطًا إذا كانت خبرة المطور الأساسية في استخدام C/C++، وصعبًا إذا كانت خبرته الأساسية في استخدام Java أو Python أو Ruby أو لغات مشابهة تُدار فيها الذاكرة تلقائيًا.

TypeScript وRust كلتاهما حديثتان نسبيًا. وهذا يعني أن كثيرًا من الأدوات لا يملك توثيقًا لهاتين اللغتين بعد. فمثلًا، سيحتاج خط devops إلى الإعداد لهاتين اللغتين، وحتى الآن لا تملك أي من أدوات devops التي نقيّمها أمثلة افتراضية لهما.

أزمنة ترجمة TypeScript وRust بطيئة نوعًا ما. وقد يرجع بعض ذلك إلى حداثة اللغتين. وقد نرغب في النظر في كيفية التخفيف من بطء أزمنة الترجمة، مثل الترجمة عند الطلب والترجمة المتزامنة وغيرها.

دعم بيئات التطوير المتكاملة (IDE) لهاتين اللغتين لم يصبح بعد شاملًا ولا من الدرجة الأولى. فمثلًا، تبيع JetBrains بيئة PyCharm بدعم من الدرجة الأولى للغة Python، لكنها لا تبيع بيئة بدعم من الدرجة الأولى للغة Rust؛ وبدلًا من ذلك يمكن لـJetBrains استخدام إضافة Rust توفر ربما 80% من دعم لغة Rust مقارنةً بدعم لغة Python.

ذو صلة

قرارات ذات صلة

سنتجه نحو خيارات النظام البيئي المتوافقة مع هاتين اللغتين.

فمثلًا، نريد اختيار بيئة IDE ذات إمكانات جيدة لهاتين اللغتين.

ومثلًا، بالنسبة إلى إطار الويب للواجهة الأمامية لدينا، من الأرجح أن نختار إطارًا يميل نحو TypeScript (مثل Vue) على إطار يميل نحو JavaScript الصرفة (مثل React).

متطلبات ذات صلة

يجب أن تدعم سلسلة أدواتنا بأكملها هاتين اللغتين.

نواتج ذات صلة

نتوقع أننا قد نصدّر بعض الأسرار إلى متغيرات البيئة.

مبادئ ذات صلة

قِس مرتين، ابنِ مرة. نعطي أولوية لبعض الأمان على بعض السرعة.

وقت التشغيل أثمن من وقت الترجمة. نعطي أولوية لاستخدام العملاء على استخدام المطورين.

ملاحظات

أي ملاحظات هنا.