مضمون پہلے شائع ہونے والے ایک جواب کے طور پر لکھا گیا تھا۔ antipodean مضمون.

پچھلے دو سے زیادہ سالوں میں میں ایک ترقی یافتہ بلنگ سسٹم کے ساتھ ایک خصوصی RADIUS سرور کو لاگو کرنے کے لیے Go کا استعمال کر رہا ہوں۔ راستے میں، میں خود زبان کی پیچیدگیاں سیکھ رہا ہوں۔ پروگرام بذات خود بہت سادہ ہیں اور اس مضمون کا مقصد نہیں ہے، لیکن خود گو استعمال کرنے کا تجربہ اپنے دفاع میں چند الفاظ کا مستحق ہے۔ گو سنجیدہ، توسیع پذیر کوڈ کے لیے تیزی سے مرکزی دھارے کی زبان بنتا جا رہا ہے۔ یہ زبان گوگل نے بنائی تھی، جہاں اسے فعال طور پر استعمال کیا جاتا ہے۔ نیچے کی سطر، میں ایمانداری سے سوچتا ہوں کہ گو زبان کا ڈیزائن غیر ذہین پروگرامرز کے لیے برا ہے۔

کمزور پروگرامرز کے لیے ڈیزائن کیا گیا؟

کمزور مسائل کی بات کرتے ہیں۔ خیالات اور خوابوں کے بارے میں مضبوط گفتگو...

گو سیکھنا بہت آسان ہے، اتنا آسان ہے کہ آپ عملی طور پر بغیر کسی تربیت کے کوڈ پڑھ سکتے ہیں۔ زبان کی یہ خصوصیت بہت سی عالمی کمپنیوں میں استعمال ہوتی ہے جب کوڈ کو غیر بنیادی ماہرین (مینیجرز، کسٹمرز وغیرہ) کے ساتھ مل کر پڑھا جاتا ہے۔ یہ ڈیزائن پر مبنی ترقی جیسے طریقوں کے لیے بہت آسان ہے۔
یہاں تک کہ نوسکھئیے پروگرامرز بھی ایک یا دو ہفتوں کے بعد کافی مہذب کوڈ تیار کرنا شروع کردیتے ہیں۔ میں نے جس کتاب سے مطالعہ کیا وہ ہے "گو پروگرامنگ" (بذریعہ مارک سمر فیلڈ)۔ کتاب بہت اچھی ہے، اس میں زبان کی بہت سی باریکیوں کو چھو لیا گیا ہے۔ جاوا، پی ایچ پی جیسی غیر ضروری طور پر پیچیدہ زبانوں کے بعد جادو کی کمی تازگی ہے۔ لیکن جلد یا بدیر، بہت سے محدود پروگرامرز کو نئے فیلڈ میں پرانے طریقے استعمال کرنے کا خیال آتا ہے۔ کیا یہ واقعی ضروری ہے؟

روب پائیک (زبان کے مرکزی نظریہ ساز) نے گو زبان کو ایک صنعتی زبان کے طور پر بنایا جو سمجھنے میں آسان اور استعمال میں موثر ہے۔ زبان کو بڑی ٹیموں میں زیادہ سے زیادہ پیداوری کے لیے ڈیزائن کیا گیا ہے اور اس میں کوئی شک نہیں ہے۔ بہت سے نوسکھئیے پروگرامرز شکایت کرتے ہیں کہ بہت سی خصوصیات ہیں جو ان میں موجود نہیں ہیں۔ سادگی کی یہ خواہش زبان کے ڈیزائنرز کا ایک شعوری فیصلہ تھا، اور پوری طرح سے یہ سمجھنے کے لیے کہ اس کی ضرورت کیوں تھی، ہمیں ڈویلپرز کی حوصلہ افزائی کو سمجھنا چاہیے اور وہ Go میں کیا حاصل کرنے کی کوشش کر رہے تھے۔

تو اسے اتنا سادہ کیوں بنایا گیا؟ روب پائیک کے چند اقتباسات یہ ہیں:

یہاں اہم نکتہ یہ ہے کہ ہمارے پروگرامرز محقق نہیں ہیں۔ وہ، ایک اصول کے طور پر، کافی نوجوان ہیں، تعلیم حاصل کرنے کے بعد ہمارے پاس آتے ہیں، شاید انہوں نے جاوا، یا C/C++، یا Python کا مطالعہ کیا ہو۔ وہ اچھی زبان نہیں سمجھ سکتے، لیکن ساتھ ہی ہم چاہتے ہیں کہ وہ اچھا سافٹ ویئر بنائیں۔ اس لیے زبان کو سمجھنے اور سیکھنے میں آسان ہونا چاہیے۔

اسے واقف ہونا چاہئے، تقریباً سی کی طرح بولنا۔ گوگل میں کام کرنے والے پروگرامرز اپنے کیریئر کا آغاز جلد کرتے ہیں اور زیادہ تر طریقہ کار کی زبانوں سے واقف ہوتے ہیں، خاص طور پر سی فیملی۔ نئی پروگرامنگ لینگویج میں فوری پیداواری صلاحیت کی ضرورت کا مطلب یہ ہے کہ زبان زیادہ بنیاد پرست نہیں ہونی چاہیے۔

دانشمندانہ الفاظ، کیا وہ نہیں ہیں؟

سادگی کے نمونے

سادگی خوبصورتی کے لیے ضروری شرط ہے۔ لیو ٹالسٹائی۔

اسے سادہ رکھنا کسی بھی ڈیزائن میں سب سے اہم مقاصد میں سے ایک ہے۔ جیسا کہ آپ جانتے ہیں، ایک پرفیکٹ پروجیکٹ وہ پروجیکٹ نہیں ہے جس میں شامل کرنے کے لیے کچھ نہ ہو، بلکہ ایسا پروجیکٹ جس سے ہٹانے کے لیے کچھ نہ ہو۔ بہت سے لوگوں کا ماننا ہے کہ پیچیدہ مسائل کو حل کرنے (یا یہاں تک کہ اظہار) کے لیے ایک پیچیدہ ٹول کی ضرورت ہے۔ تاہم، یہ نہیں ہے. آئیے مثال کے طور پر PERL زبان کو لیں۔ زبان کے نظریاتی ماہرین کا خیال تھا کہ ایک پروگرامر کے پاس ایک مسئلہ کو حل کرنے کے لیے کم از کم تین مختلف طریقے ہونے چاہئیں۔ گو زبان کے نظریاتی ماہرین نے ایک مختلف راستہ اختیار کیا؛ انہوں نے فیصلہ کیا کہ ایک راستہ، لیکن واقعی ایک اچھا، مقصد کو حاصل کرنے کے لیے کافی ہے۔ اس نقطہ نظر کی ایک سنجیدہ بنیاد ہے: واحد طریقہ سیکھنا آسان اور بھولنا مشکل ہے۔

بہت سے مہاجرین شکایت کرتے ہیں کہ زبان میں خوبصورت تجریدات نہیں ہیں۔ جی ہاں، یہ سچ ہے، لیکن یہ زبان کے اہم فوائد میں سے ایک ہے. زبان میں کم از کم جادو ہوتا ہے - لہذا پروگرام کو پڑھنے کے لیے کسی گہرے علم کی ضرورت نہیں ہے۔ جہاں تک کوڈ کی زبانی بات ہے تو یہ کوئی مسئلہ نہیں ہے۔ ایک اچھی طرح سے لکھا ہوا گولانگ پروگرام عمودی طور پر پڑھتا ہے، جس میں بہت کم یا کوئی ساخت نہیں ہے۔ اس کے علاوہ، کسی پروگرام کو پڑھنے کی رفتار اس کو لکھنے کی رفتار سے کم از کم ایک ترتیب سے زیادہ ہے۔ اگر آپ غور کرتے ہیں کہ تمام کوڈ میں یکساں فارمیٹنگ ہے (بلٹ ان gofmt کمانڈ کا استعمال کرتے ہوئے کیا گیا ہے)، تو پھر چند اضافی لائنوں کو پڑھنا کوئی مسئلہ نہیں ہے۔

بہت اظہار خیال نہیں ہے۔

فن اس وقت برداشت نہیں کرتا جب اس کی آزادی محدود ہو جاتی ہے۔ درستگی اس کی ذمہ داری نہیں ہے۔

سادگی کی خواہش کی وجہ سے گو میں ایسی تعمیرات کا فقدان ہے جسے دوسری زبانوں میں ان کے عادی لوگ قدرتی چیز سمجھتے ہیں۔ پہلے تو یہ کچھ تکلیف دہ ہو سکتا ہے، لیکن پھر آپ نے محسوس کیا کہ پروگرام بہت آسان اور پڑھنے میں زیادہ واضح ہے۔

مثال کے طور پر، ایک کنسول یوٹیلیٹی جو stdin پڑھتی ہے یا کمانڈ لائن آرگومینٹس سے فائل اس طرح نظر آئے گی:

package main

import (
    "bufio"
    "flag"
    "fmt"
    "log"
    "os"
)

func main() {

    flag.Parse()

    scanner := newScanner(flag.Args())

    var text string
    for scanner.Scan() {
        text += scanner.Text()
    }

    if err := scanner.Err(); err != nil {
        log.Fatal(err)
    }

    fmt.Println(text)
}

func newScanner(flags []string) *bufio.Scanner {
    if len(flags) == 0 {
        return bufio.NewScanner(os.Stdin)
    }

    file, err := os.Open(flags[0])

    if err != nil {
        log.Fatal(err)
    }

    return bufio.NewScanner(file)
}

ڈی میں اسی مسئلے کا حل، اگرچہ یہ کچھ چھوٹا نظر آتا ہے، پڑھنا آسان نہیں ہے۔

import std.stdio, std.array, std.conv;

void main(string[] args)
{
    try
    {
        auto source = args.length > 1 ? File(args[1], "r") : stdin;
        auto text   = source.byLine.join.to!(string);

        writeln(text);
    }
    catch (Exception ex)
    {
        writeln(ex.msg);
    }
}

نقل کرنے کا جہنم

انسان اپنے اندر جہنم اٹھاتا ہے۔ مارٹن لوتھر۔

جینرک کی کمی کے معاملے میں ابتدائی لوگ مسلسل Go کے بارے میں شکایت کرتے ہیں۔ اس مسئلے کو حل کرنے کے لیے، ان میں سے اکثر براہ راست کوڈ کاپی کرنے کا استعمال کرتے ہیں۔ مثال کے طور پر، انٹیجرز کی فہرست کا خلاصہ کرنے کے لیے ایک فنکشن، ایسے پیشہ ور افراد کا خیال ہے کہ فعالیت کو ہر ایک قسم کے ڈیٹا کے لیے سادہ کاپی پیسٹ کرنے کے علاوہ کسی اور طریقے سے لاگو نہیں کیا جا سکتا۔

package main

import "fmt"

func int64Sum(list []int64) (uint64) {
    var result int64 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

func int32Sum(list []int32) (uint64) {
    var result int32 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

func main() {

    list32 := []int32{1, 2, 3, 4, 5}
    list64 := []int64{1, 2, 3, 4, 5}

    fmt.Println(int32Sum(list32))
    fmt.Println(int64Sum(list64))
}

زبان میں ایسی تعمیرات کو عملی جامہ پہنانے کے لیے کافی ذرائع ہیں۔ مثال کے طور پر، عام پروگرامنگ ٹھیک ہو جائے گا.

package main

import "fmt"

func Eval32(list []int32, fn func(a, b int32)int32) int32 {
    var res int32
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int32Add(a, b int32) int32 {
    return a + b
}

func int32Sub(a, b int32) int32 {
    return a + b
}

func Eval64(list []int64, fn func(a, b int64)int64) int64 {
    var res int64
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int64Add(a, b int64) int64 {
    return a + b
}

func int64Sub(a, b int64) int64 {
    return a - b
}

func main() {

    list32 := []int32{1, 2, 3, 4, 5}
    list64 := []int64{1, 2, 3, 4, 5}

    fmt.Println(Eval32(list32, int32Add))
    fmt.Println(Eval64(list64, int64Add))
    fmt.Println(Eval64(list64, int64Sub))
}

اور، اگرچہ ہمارا کوڈ پچھلے کیس سے کچھ لمبا نکلا، لیکن یہ عام ہو گیا ہے۔ لہذا، ہمارے لیے تمام ریاضی کے عمل کو نافذ کرنا مشکل نہیں ہوگا۔

بہت سے لوگ کہیں گے کہ D میں ایک پروگرام نمایاں طور پر چھوٹا لگتا ہے، اور وہ درست ہوں گے۔

import std.stdio;
import std.algorithm;

void main(string[] args)
{
    [1, 2, 3, 4, 5].reduce!((a, b) => a + b).writeln;
}

تاہم، یہ صرف چھوٹا ہے، لیکن زیادہ درست نہیں، کیونکہ ڈی کا نفاذ غلطی سے نمٹنے کے مسئلے کو مکمل طور پر نظر انداز کرتا ہے۔

حقیقی زندگی میں، جیسے جیسے منطق کی پیچیدگی بڑھتی ہے، خلیج تیزی سے کم ہوتی جاتی ہے۔ یہ خلا اس وقت اور بھی تیزی سے ختم ہو جاتا ہے جب آپ کو کوئی ایسا عمل انجام دینے کی ضرورت ہوتی ہے جو معیاری لینگویج آپریٹرز کے استعمال سے نہیں کی جا سکتی۔

برقرار رکھنے، توسیع پذیری، اور پڑھنے کی اہلیت کے لحاظ سے، میری رائے میں، گو زبان جیت جاتی ہے، حالانکہ یہ لفظی طور پر ہار جاتی ہے۔

کچھ معاملات میں عمومی پروگرامنگ ہمیں ناقابل تردید فوائد فراہم کرتی ہے۔ یہ واضح طور پر ترتیب والے پیکیج سے واضح ہے۔ لہذا، کسی بھی فہرست کو ترتیب دینے کے لیے، ہمیں صرف sort.Interface انٹرفیس کو لاگو کرنے کی ضرورت ہے۔

import "sort"

type Names []string

func (ns Names) Len() int {
    return len(ns)
}

func (ns Names) Less(i, j int) bool {
    return ns[i] < ns[j]
}

func (ns Names) Swap(i, j int) {
    ns[i], ns[j] = ns[j], ns[i]
}

func main() {
    names := Names{"London", "Berlin", "Rim"}
    sort.Sort(names)
}

اگر آپ کوئی اوپن سورس پروجیکٹ لیتے ہیں اور grep "interface{}" -R کمانڈ چلاتے ہیں، تو آپ دیکھیں گے کہ کتنی بار الجھا ہوا انٹرفیس استعمال ہوتا ہے۔ قریبی ذہن رکھنے والے کامریڈ فوراً کہیں گے کہ یہ سب جنرک کی کمی کی وجہ سے ہے۔ تاہم، یہ ہمیشہ کیس نہیں ہے. آئیے ڈیلفی کو ایک مثال کے طور پر لیں۔ انہی جنرکس کی موجودگی کے باوجود، اس میں صوابدیدی ڈیٹا کی قسموں کے ساتھ آپریشنز کے لیے ایک خاص VARIANT قسم ہے۔ گو زبان بھی ایسا ہی کرتی ہے۔

تپ سے چڑیوں تک

اور سٹریٹ جیکٹ کو جنون کے سائز کے مطابق ہونا چاہیے۔ Stanislav Lec.

بہت سے انتہائی شائقین یہ دعوی کر سکتے ہیں کہ گو کے پاس جنرک بنانے کا ایک اور طریقہ کار ہے - عکاسی۔ اور وہ درست ہوں گے... لیکن صرف شاذ و نادر ہی صورتوں میں۔

روب پائیک ہمیں خبردار کرتا ہے:

یہ ایک طاقتور ٹول ہے جسے احتیاط کے ساتھ استعمال کیا جانا چاہیے۔ جب تک سختی سے ضروری نہ ہو اس سے گریز کرنا چاہیے۔

ویکیپیڈیا ہمیں مندرجہ ذیل بتاتا ہے:

عکاسی سے مراد وہ عمل ہے جس کے دوران ایک پروگرام عمل درآمد کے دوران اپنی ساخت اور طرز عمل کی نگرانی اور اس میں ترمیم کرسکتا ہے۔ پروگرامنگ کے پیراڈائم کی بنیادی عکاسی کو عکاس پروگرامنگ کہا جاتا ہے۔ یہ میٹا پروگرامنگ کی ایک قسم ہے۔

تاہم، جیسا کہ آپ جانتے ہیں، آپ کو ہر چیز کی ادائیگی کرنی ہوگی۔ اس صورت میں یہ ہے:

• پروگرام لکھنے میں دشواری
• پروگرام پر عمل درآمد کی رفتار

لہذا، عکاسی کو احتیاط کے ساتھ استعمال کیا جانا چاہئے، جیسے بڑے صلاحیت والے ہتھیار۔ عکاسی کے بغیر سوچے سمجھے استعمال سے پڑھے جانے والے پروگرامز، مستقل غلطیاں اور کم رفتار ہوتی ہے۔ ایک سنوب پروگرامر کے لیے صرف اتنا ہے کہ وہ اپنے کوڈ کو دوسرے، زیادہ عملی اور معمولی ساتھیوں کے سامنے دکھا سکے۔

الیون سے ثقافتی سامان؟ نہیں، کئی زبانوں سے!

قسمت کے ساتھ ساتھ قرض بھی ورثاء پر چھوڑ دیا جاتا ہے۔

اس حقیقت کے باوجود کہ بہت سے لوگوں کا ماننا ہے کہ زبان مکمل طور پر C ورثے پر مبنی ہے، ایسا نہیں ہے۔ زبان بہترین پروگرامنگ زبانوں کے بہت سے پہلوؤں کو شامل کرتی ہے۔

نحو

سب سے پہلے، گراماتی ڈھانچے کا نحو C زبان کے نحو پر مبنی ہے۔ تاہم، ڈیلفی زبان کا بھی ایک خاص اثر تھا۔ اس طرح، ہم دیکھتے ہیں کہ بے کار قوسین، جو پروگرام کی پڑھنے کی اہلیت کو بہت حد تک کم کرتے ہیں، کو مکمل طور پر ہٹا دیا گیا ہے۔ اس زبان میں ":=" آپریٹر بھی ہوتا ہے جو DELPHI زبان میں شامل ہے۔ پیکیجز کا تصور ADA جیسی زبانوں سے لیا گیا ہے۔ غیر استعمال شدہ اداروں کا اعلان PROLOG زبان سے لیا گیا ہے۔

الفاظ

پیکجز ڈیلفی زبان کے الفاظ پر مبنی تھے۔ ہر پیکج ڈیٹا اور کوڈ کو سمیٹتا ہے اور اس میں نجی اور عوامی ادارے شامل ہیں۔ یہ آپ کو پیکیج انٹرفیس کو کم سے کم کرنے کی اجازت دیتا ہے۔

وفد کے طریقہ کار کے ذریعے عمل درآمد ڈیلفی زبان سے لیا گیا تھا۔

تالیف

یہ بغیر کسی وجہ کے نہیں ہے کہ ایک لطیفہ ہے: Go اس وقت تیار کیا گیا تھا جب ایک C پروگرام مرتب کیا جا رہا تھا۔ زبان کی ایک خوبی اس کی انتہائی تیز تالیف ہے۔ یہ خیال DELPHI زبان سے لیا گیا تھا۔ ہر گو پیکج ڈیلفی ماڈیول سے مطابقت رکھتا ہے۔ یہ پیکجز صرف اس صورت میں دوبارہ مرتب کیے جاتے ہیں جب واقعی ضروری ہو۔ اس لیے، اگلی ترمیم کے بعد، آپ کو پورا پروگرام مرتب کرنے کی ضرورت نہیں ہے، بلکہ صرف ان تبدیل شدہ پیکجوں اور پیکجوں کو دوبارہ مرتب کریں جو ان تبدیل شدہ پیکجوں پر منحصر ہیں (اور تب بھی، صرف اس صورت میں جب پیکج کے انٹرفیس بدل گئے ہوں)۔

اعلیٰ سطحی تعمیرات

زبان میں بہت سی مختلف اعلیٰ سطحی تعمیرات شامل ہیں جن کا تعلق کسی بھی طرح سے نچلی سطح کی زبانوں سے نہیں ہے جیسے C۔

• سٹرنگز
• ہیش ٹیبلز
• سلائسس
• بطخ کی ٹائپنگ RUBY جیسی زبانوں سے مستعار لی گئی ہے (جسے بدقسمتی سے، بہت سے لوگ اس کی پوری صلاحیت کو نہیں سمجھتے یا استعمال نہیں کرتے)۔

میموری کا انتظام

میموری مینجمنٹ عام طور پر ایک الگ مضمون کا مستحق ہے۔ اگر C++ جیسی زبانوں میں، کنٹرول مکمل طور پر ڈویلپر پر چھوڑ دیا جاتا ہے، تو بعد کی زبانوں جیسے DELPHI میں، ایک حوالہ شماری ماڈل استعمال کیا جاتا تھا۔ اس نقطہ نظر کے ساتھ، سائکلک حوالہ جات کی اجازت نہیں تھی، چونکہ یتیم کلسٹرز بنائے گئے تھے، پھر گو نے ایسے کلسٹرز (جیسے C#) کی بلٹ ان ڈیٹیکشن کی ہے۔ اس کے علاوہ، ردی کی ٹوکری جمع کرنے والا زیادہ تر فی الحال معلوم نفاذ سے زیادہ موثر ہے اور اسے پہلے ہی بہت سے حقیقی وقت کے کاموں کے لیے استعمال کیا جا سکتا ہے۔ زبان خود ان حالات کو پہچانتی ہے جب اسٹیک پر متغیر کو ذخیرہ کرنے کی قدر مختص کی جا سکتی ہے۔ اس سے میموری مینیجر پر بوجھ کم ہوتا ہے اور پروگرام کی رفتار بڑھ جاتی ہے۔

Concurrency اور Concurrency

زبان کی ہم آہنگی اور مسابقت قابل تعریف ہے۔ کوئی بھی نچلی سطح کی زبان دور سے بھی Go کا مقابلہ نہیں کر سکتی۔ منصفانہ ہونے کے لئے، یہ قابل ذکر ہے کہ ماڈل زبان کے مصنفین کی طرف سے ایجاد نہیں کیا گیا تھا، لیکن صرف اچھی پرانی ADA زبان سے ادھار لیا گیا تھا. یہ زبان تمام سی پی یوز کا استعمال کرتے ہوئے لاکھوں متوازی کنکشنز پر کارروائی کرنے کی اہلیت رکھتی ہے، جبکہ تعطل اور نسل کے حالات کے ساتھ کم پیچیدہ مسائل کا آرڈر رکھتے ہیں جو ملٹی تھریڈڈ کوڈ کے لیے عام ہیں۔

اضافی فوائد

منافع بخش ہو گا تو سب بے لوث ہو جائیں گے۔

زبان ہمیں بے شمار فوائد بھی فراہم کرتی ہے:

• پروجیکٹ کی تعمیر کے بعد ایک ہی قابل عمل فائل ایپلی کیشنز کی تعیناتی کو بہت آسان بناتی ہے۔
• جامد ٹائپنگ اور قسم کا اندازہ آپ کے کوڈ میں غلطیوں کی تعداد کو نمایاں طور پر کم کر سکتا ہے، یہاں تک کہ تحریری ٹیسٹ کے بغیر۔ میں کچھ پروگرامرز کو جانتا ہوں جو بغیر ٹیسٹ لکھے کرتے ہیں اور ان کے کوڈ کے معیار کو کوئی خاص نقصان نہیں پہنچاتا۔
• بہت آسان کراس کمپائلیشن اور معیاری لائبریری کی بہترین پورٹیبلٹی، جو کراس پلیٹ فارم ایپلی کیشنز کی ترقی کو بہت آسان بناتی ہے۔
• RE2 ریگولر ایکسپریشن تھریڈ سے محفوظ ہیں اور ان پر عمل درآمد کے اوقات متوقع ہیں۔
• ایک طاقتور معیاری لائبریری جو زیادہ تر پروجیکٹس کو تھرڈ پارٹی فریم ورک کے بغیر کرنے کی اجازت دیتی ہے۔
• زبان اتنی طاقتور ہے کہ مسئلہ کو حل کرنے کے بجائے اس پر توجہ مرکوز کر سکے، پھر بھی اتنی کم سطح ہے کہ مسئلہ کو موثر طریقے سے حل کیا جا سکتا ہے۔
• گو ایکو سسٹم میں پہلے سے ہی تمام مواقع کے لیے تیار کردہ ٹولز موجود ہیں: ٹیسٹ، دستاویزات، پیکیج مینجمنٹ، طاقتور لنٹرز، کوڈ جنریشن، ریس کنڈیشن ڈیٹیکٹر، وغیرہ۔
• گو ورژن 1.11 نے بلٹ ان سیمنٹک انحصاری انتظام متعارف کرایا، جو مقبول VCS ہوسٹنگ کے اوپر بنایا گیا ہے۔ گو ایکو سسٹم بنانے والے تمام ٹولز ان سروسز کو ان سے کوڈ ڈاؤن لوڈ، بنانے اور انسٹال کرنے کے لیے استعمال کرتے ہیں۔ اور یہ بہت اچھا ہے۔ ورژن 1.11 کی آمد کے ساتھ، پیکیج ورژننگ کا مسئلہ بھی مکمل طور پر حل ہو گیا۔
• چونکہ زبان کا بنیادی خیال جادو کو کم کرنا ہے، اس لیے زبان ڈویلپرز کو واضح طور پر غلطی سے نمٹنے کے لیے ترغیب دیتی ہے۔ اور یہ درست ہے، کیونکہ دوسری صورت میں، یہ غلطی سے نمٹنے کے بارے میں بالکل بھول جائے گا۔ ایک اور چیز یہ ہے کہ زیادہ تر ڈویلپر غلطی سے نمٹنے کو جان بوجھ کر نظر انداز کرتے ہیں، غلطی کو اوپر کی طرف آگے بڑھانے کے بجائے ان پر کارروائی کرنے کو ترجیح دیتے ہیں۔
• زبان کلاسیکی OOP طریقہ کار کو نافذ نہیں کرتی ہے، کیونکہ اس کی خالص شکل میں Go میں کوئی ورچوئلٹی نہیں ہے۔ تاہم، انٹرفیس استعمال کرتے وقت یہ کوئی مسئلہ نہیں ہے۔ OOP کی غیر موجودگی ابتدائی افراد کے داخلے میں رکاوٹ کو نمایاں طور پر کم کرتی ہے۔

برادری کے فائدے کے لیے سادگی

اسے پیچیدہ کرنا آسان ہے، آسان کرنا مشکل ہے۔

Go کو سادہ بنانے کے لیے ڈیزائن کیا گیا تھا اور یہ اس مقصد میں کامیاب ہوتا ہے۔ یہ سمارٹ پروگرامرز کے لیے لکھا گیا تھا جو ٹیم ورک کے فوائد کو سمجھتے ہیں اور انٹرپرائز کی سطح کی زبانوں کی لامتناہی تغیرات سے تنگ ہیں۔ اس کے ہتھیاروں میں نحوی ڈھانچے کا ایک نسبتاً چھوٹا سیٹ ہونے کی وجہ سے، یہ عملی طور پر وقت کے ساتھ تبدیلیوں کے تابع نہیں ہوتا ہے، اس لیے ڈویلپرز کے پاس ترقی کے لیے کافی وقت ہوتا ہے، نہ کہ زبان کی اختراعات کا لامتناہی مطالعہ کرنے کے لیے۔

کمپنیوں کو بہت سے فوائد بھی حاصل ہوتے ہیں: داخلے کی کم رکاوٹ انہیں فوری طور پر ایک ماہر تلاش کرنے کی اجازت دیتی ہے، اور زبان کی تبدیلی انہیں 10 سال بعد بھی ایک ہی کوڈ کو استعمال کرنے کی اجازت دیتی ہے۔

حاصل يہ ہوا

دماغ کے بڑے سائز نے کبھی کسی ہاتھی کو نوبل انعام یافتہ نہیں بنایا۔

ان پروگرامرز کے لیے جن کی ذاتی انا ٹیم کے جذبے پر فوقیت رکھتی ہے، نیز نظریاتی جو علمی چیلنجوں اور لامتناہی "خود کی بہتری" کو پسند کرتے ہیں، ان کے لیے زبان واقعی خراب ہے، کیونکہ یہ ایک عام مقصد کی فنکارانہ زبان ہے جو آپ کو حاصل کرنے کی اجازت نہیں دیتی۔ اپنے کام کے نتیجے سے جمالیاتی خوشی حاصل کریں اور ساتھیوں کے سامنے اپنے آپ کو پیشہ ور ظاہر کریں (بشرطیکہ ہم ذہانت کی پیمائش ان معیاروں سے کریں، نہ کہ IQ سے)۔ زندگی کی ہر چیز کی طرح یہ بھی ذاتی ترجیحات کا معاملہ ہے۔ تمام قابل قدر اختراعات کی طرح، زبان نے پہلے ہی آفاقی انکار سے لے کر بڑے پیمانے پر قبولیت تک کا سفر طے کر لیا ہے۔ زبان اپنی سادگی میں ہوشیار ہے، اور جیسا کہ آپ جانتے ہیں، ہر چیز آسان ہے!

ماخذ: www.habr.com