لغة البرمجة Go

تم تطوير Go من قبل شركة Google لتلبية احتياجات عالم محدد بواسطة معالجات متعددة النواة وأنظمة شبكية ومجموعات حوسبة وتطبيقات ويب وتم تطويرها لتكون سريعة في الكتابة مع تضمين جميع الميزات الحديثة مثل التزامن وجمع القمامة ويهدف تطوير Go أيضا إلى تسهيل إدارة التبعيات وتمكين التطبيقات من التوسع بسهولة أكبر.


أشياء قد لن تحبها حول لغة البرمجة Go
1. ليست كائنية التوجه
هذا إن كنت تظن أنها كذلك، فلا يوجد مفهوم الصنف (Class) ولا الكائنات (Objects) وبالتالي لا يوجد وراثة (inheritance). مع ذلك فإن Go تحمل بضعا من مزايا البرمجة الكائنية كتوفيرها لـ Interface و دوال البنيات (Struct methods) وتركيب البنيات (Struct composition).

لماذا؟ مؤسسي اللغة يرون أن اللغات كائنية التوجه تحمل العديد من العيوب والتعقيدات التي يمكن إلغاؤها بالتخلي عن بعض هذه المفاهيم كلية. حتى مبرمجي Java أنفسهم ينصحون بـ Composition مثلا في كثير من الأحيان عوض inheritance، مؤسسي اللغة ممن يرون أن البرمجة كائنية التوجه غالبا ما تكون فكرة سيئة -تقنيا-.

2. لا توجد معالجة للاستثناءات Exception Handling
قد تكون هذه نتيجة طبيعية بسبب غياب مفهوم البرمجة الكائنية لدى Go، فمعالجة الأخطاء في Go تتم بطريقة واضحة وتقليدية نوعا ما، حيث أن الأخطاء تُرجع كقيم عادية من نوع error. حيث error هو نوع بدائي في حد ذاته مثله مثل أي نوع أصلي آخر (int, string .. الخ). مع ذلك تسمح لك Go بقذف خطأ للحالات الاستثنائية عبر الكلمة المفتاحية panic (أشبه بـ raise أو throw في باقي اللغات) وكذا التعافي من هذه الأخطاء عن طريق recover.

3. لا توجد معامِلات افتراضية أو اختيارية يمكن تمريرها للدوال (default/optional arguments)
ربما قد اعتدت في لغات البرمجة الأخرى على القيام بشيء مثل:

function listFolders(path, subfolders=false, recursive=false){ ... }
لكن في Go لن يمكنك تمرير subfolder=false ولا recursive=false كإمضاء للدالة listFolders لأنها لن تقبل مثل هذه المعاملات الافتراضية/الاختيارية، وسينتج عن ذلك خطأ عند التجميع (compile error).

لماذا؟ يرى مؤسسوا اللغة أن هذه السلوكيات تساهم في بناء واجهات برمجية (API) غير ثابتة أو تساهم في جعل تصرفها غير مُتوقع. في مثالنا السابق مثلا، هم يفضلون كتابة الدالة من دون معاملات افتراضية، أي:

func listFolders(path string, subfolders bool, recursive bool) { ... }
يجبرك هذا على كتابة التصرف الذي تريده من الدالة بشكل صريح عوض ترك الواجهة البرمجية تملي عليك التصرف الافتراضي، هذا لتقليل الأخطاء البشرية. أيضا قد يدفعك هذا إلى كتابة ثلاث دوال، كل بتصرفها الخاص الواضح من اسمها، مثال: listFolders, listFoldersRecursivly و listFoldersWithFirstLevelSubFolders.

4. لا توجد ميزة إثقال الدوال (Method Overloading)
لنفس الأسباب السابقة، فإنه لا يوجد Method overloading، أي لا يمكنك إعادة تعريف دالة تحمل نفس الاسم لكن بإمضاء مغاير. مثلا، إذا وُجدت دالة باسم:

func listFolders(path string) { ... }
فلا يمكنك إنشاء دالة أخرى بنفس الاسم لكن بإمضاء مغاير مثل:

func listFolder(path string, level int) { ... }
بل عليك تغيير اسمها إلى مثلا:

dunc listFolderToLevel(path string, level int) { ... }
على الرغم من ذلك فهناك طريقة غير مباشرة لجعل دالة ما تقبل قيما اعتباطية عبر جعل الإمضاء من نوع {}interface سنتطرق إليها في الدروس القادمة.

5. لا وجود للعموميات (generics)
تمكّنك باقي اللغات من كتابة دوال أو أصناف عامة، حيث لا تصرّح عند كتابتها بنوع المعاملات التي تقبلها لكن تترك لها مهمة معرفة نوع المعاملات لاحقا عند استدعائها، لعل أقرب مثال هو ما توفره لغة Java مثلا في صنف <List<T حيث T يرمز إلى أي نوع يتم تحديده لاحقا، بالتالي يمكن إنشاء <List<String أو <List<Integer بكل سهولة مع الحفاظ على نفس الوظائف والعمليات التي يمكن إجراؤها على القائمة List بشكل عام.

لا يوجد في Go مثل هذا، وعوضا عن ذلك فهناك {}interface كنوع شامل يرضي جميع الأنواع، لكنه ليس كبديل تام لـ Generics.

لماذا؟ سبب عدم توفر العموميات (Generics) في Go هو أن مؤسسيها لم يتبيّنوا بعد الطريقة الأنسب لهم لإضافة هذه الميزة إلى اللغة دون زيادة حِمل أثناء وقت التشغيل (run-time).

6. Go لُغة مملة كما أنها ليست أفضل لغة برمجة!
لشدة بساطة اللغة وعدم إتيانها بشيء جديد، فإن الكثيرين يعتبرها لغة مملة. فعدد الكلمات المفتاحية بها والأنواع الأصلية فيها ضئيل مقارنة بباقي اللغات، كما أنها تقلل كثيرا من وجود أكثر من طريقة للقيام بمهمة معينة. حتى أنها لا تحتوي على حلقة while وتقتصر فقط على حلقة for، الكثيرون يعتبرون هذا من مزايا اللغة، لكني ذكرتها لك حتى لا تتوقع شيئا جديدا يصلح للتباهي.

أيضا لن تسمح لك اللغة بترك متغير دون استعمال أو استيراد شيء غير مستعمل (unused import/variable) ولن يقبل المُجمع (compiler) أبدا بذلك.

7. لغة عنيدة
مؤسسوا اللغة متشبثون برأيهم وقراراتهم في تصميم اللغة، فلا تتوقع تغيرات جوهرية قد تحدث على المدى القريب أو المتوسط في اللغة أو تغيرات في طريقة القيام بالأمور وسلوك المُجمّع (compiler). ولا داعي لفتح نقاشات فارغة حول تصميم اللغة وعيوبها إلا إذا كنت في نفس مستوى خبرتهم وحكمتهم.

هم نفسهم يصرحون بهذا، ويذكرون أن هناك خيارات ولغات برمجة أخرى إن لم تعجبك Go.

8. لا يوجد إجماع على مدير حزم واحد
تملك بايثون pip، وجافاسكريب تملك npm، وغيرهم من اللغات تملك مدير حزم (package manager) شهير أو متفق عليه، لا تخلو Go من مدير حزم، فهي تملك الكثير من ذلك، لكنها لم تتفق بعد على مدير حزم واحد ولا عن كيفية جلب وسرد الاعتماديات بطريقة قياسية، لكن حديثا يتم العمل على ذلك عبر مفهوم Vendoring.

هذه الأمور الثمانية، للذكر وليس للحصر من أشد الانتقادات التي توجّه إلى Go كلغة برمجة، فإن كنت توافقها فقد لا تناسبك اللغة، وإن كنت ترى أن من ورائها حكمة -مثلي- فأكمل قراءة المقال حول أمور قد تعجبك حول Go.