मैंने एक नई भाषा चुनने की अपनी यात्रा में गो को आज़माने का फैसला किया जो मेरे करियर और रुचियों के लिए उपयोगी होगी। इस बार मैं गो पर जा रहा हूं। मुझे लगता है कि पहली छाप के अनुसार, यह बहुत अच्छा है।

यह एक निर्देशित दौरा नहीं है, और यकीनन, कुछ व्यक्तिगत अनुस्मारक के रूप में, मेरे अलावा किसी और के लिए नहीं लिखा गया है।

मैंने खुद को इसके लिए ओस-रिलीज़-क्यू नामक एक छोटा प्रोजेक्ट दिया। मेरा इरादा अपने द्वारा प्रबंधित किसी भी सिस्टम पर एक बाइनरी रखने में सक्षम होना था, ताकि मैं बिल्कुल वही जानकारी प्रिंट कर सकूं जिसकी मुझे आवश्यकता है, इसके लिए पार्स करने या आंख-मिचौली करने की आवश्यकता नहीं है।

पहली बाधा: आयात

वेब पर खोज करने से अन्य लोगों के पैकेजों को आयात करने के बारे में तो बहुत कुछ बताया जाता है, लेकिन स्वयं के कोड को व्यवस्थित करने के बारे में बहुत कम बात की जाती है। यहां तक ​​कि दस्तावेज़ भी चिंताओं को अलग करने के बजाय आगे बढ़ने पर ध्यान केंद्रित करते हैं।

मुझे हर भाषा में इस बाधा का सामना करना पड़ता है, क्योंकि प्रत्येक भाषा का अपना विशिष्ट दर्शन होता है कि इसे कैसे करना है, और प्रत्येक के पास क्या सीमाएं हैं या क्या लगाती हैं।

मूल बातें सीखने के लिए मैंने जो भी गतिविधियाँ कीं, उनमें से मुख्य रूप से पायथन पृष्ठभूमि से आने के कारण, मेरे कोड को कई फ़ाइलों में विभाजित करना वह चीज़ थी जिसके उत्तर पाने में मुझे सबसे अधिक समय लगा। संक्षेप में, मुझे निम्नलिखित मिला:

• शीर्ष स्तर पर मॉड्यूल मॉड्यूल-नाम घोषित करने के लिए एक go.mod की आवश्यकता होती है
• फिर मैं शीर्ष स्तर पर एक src/ निर्देशिका सेट कर सकता हूं, और एक src/main.go जिसमें मैं अपना मुख्य फ़ंक्शन रख सकता हूं, शीर्ष पर एक पैकेज मुख्य घोषणा के साथ
• अन्य फ़ाइलों में कोड डालना एक पैकेज मुख्य घोषणा के साथ src/others.go जैसी फ़ाइल बनाने जितना ही सरल है।
• सभी फ़ंक्शन और वेरिएबल सीधे पैकेज मुख्य की किसी भी अन्य फ़ाइल में उपलब्ध हो जाते हैं, लेकिन फ़ाइलों को गो बिल्ड FILES कॉल पर स्पष्ट रूप से बताया जाना चाहिए

स्थानीय सबमॉड्यूल के लिए, सबमॉड्यूल को एक फ़ोल्डर में रहना चाहिए। यह एक पैकेज सबमॉड्यूल-नाम घोषित कर सकता है।

मान लीजिए कि यह src/submod/ में है, मुख्य कार्यान्वयनकर्ता src/submod/submod.go में है। Main.go में हम "module-name/src/submod" आयात करते हैं (go.mod से मॉड्यूल-नाम खींचकर)। और फिर हम सबमॉड.सोमफंक्शन() को कॉल कर सकते हैं।

हम ध्यान दें कि सबमॉड्यूल फ़ंक्शन केवल आयातकों के लिए उपलब्ध हैं यदि उनका नाम बड़े अक्षर से शुरू होता है। इसलिए सबमोड.मायफंक्शन() नहीं करना चाहिए - इसे सबमोड.मायफंक्शन() होना चाहिए।

सबमॉड्यूल और आयात के आसपास निश्चित रूप से अन्य विचार भी हैं, लेकिन जहां तक ​​कोड को व्यवस्थित और अलग रखने की बात है, तो यह आवश्यक है।

चीजों को व्यवस्थित रखने के लिए, मैंने केवल एक फ़ाइल को पैकेज मुख्य घोषित करने और बाकी को सबमॉड्यूल में अलग करने का प्रलोभन दिया - ये फाइलों की गो बिल्ड फाइल्स सूची में घोषित किए बिना स्वचालित रूप से आयात हो जाते हैं।

बुनियादी कार्य करना

गो की इस विशिष्टता को हल करने के बाद, बाकी चीजें काफी आसानी से सही जगह पर आ गईं। प्रत्येक बुनियादी कार्य के लिए निश्चित रूप से एक StackOverflow प्रविष्टि, या एक GoByExample.com पृष्ठ, और अधिक मूलतः, Go भाषा संदर्भ होता था।

• स्ट्रिंग हैंडलिंग स्ट्रिंग पैकेज के माध्यम से किया जाता है
• ऐरे हैंडलिंग में कई मूल कार्य होते हैं, जिनमें से बेस_एरे = एपेंड (बेस_एरे, आइटम 1, आइटम 2) पैटर्न - यह एपेंड (बेस, अन्य_एरे ...) के माध्यम से दूसरे के मानों के साथ एक एरे को विस्तारित करने के लिए भी काम करता है।
• त्रुटि प्रबंधन आमतौर पर त्रुटि ऑब्जेक्ट को पास करके किया जाता है, लेकिन जरूरी नहीं।
• एक आसान पूर्व-कॉन्फ़िगर किए गए नो-फ़फ़िंग लॉग के लिए एक "लॉग" lib मौजूद है। इसमें एक log.Fatal(message) कॉल शामिल है जो एक त्रुटि लॉग करता है, साथ ही तुरंत बाहर निकल जाता है।
• exec.Command(base, args...) पैटर्न का उपयोग करके "os/exec" लाइब्रेरी के माध्यम से उपप्रक्रियाओं को कॉल करना आसान है

दो विशेष रूप से सामान्य कार्य अपने स्वयं के पैराग्राफ के लायक हैं।

त्रुटि प्रबंधन

बुनियादी त्रुटि प्रबंधन को अक्सर बोझिल होने के रूप में टिप्पणी की जाती है, वस्तुतः नियंत्रण प्रवाह के बीच त्रुटियों को संभालने की आवश्यकता होती है। यह कोशिश/पकड़ वर्कफ़्लो से आने वाले प्रोग्रामर्स के लिए अभिशाप हो सकता है, लेकिन समस्या को उस बिंदु पर संभालना जहां यह हो सकता है, इतना बुरा नहीं है।

// explicit return item `err` forces us to be aware of it
// but having the ability to check it in the same breath is not so bad
if result, err := someCall(); err != nil {
    log.Fatal("Sorry.")
}

// Equally valid is
/*
result, err := someCall()
if err != nil {
    log.Fatal("Sorry")
}
*/

fmt.Println(result)

प्रयास/पकड़ने के तरीके की तुलना करें

try:
    result = someCall()
    print(result)
except:
    print("Sorry") # a little divorced from potential origin of error
    sys.exit(1)

तर्क विश्लेषण

मैं मदद नहीं कर सकता लेकिन महसूस करता हूं कि फ़्लैग्स लाइब्रेरी का कार्यान्वयन थोड़ा आधा-अधूरा है। जाहिर तौर पर लोग इसके आदी हो चुके हैं और इसके वर्तमान स्वरूप में इसके अस्तित्व को देखते हुए इससे सहमत हैं।

कॉलिंग प्रोग्राम -फ्लैग arg1 arg2 हमें वह टॉगल देता है जिसे करने के लिए फ़्लैग सेट किया गया है, और स्थितियाँ := flags.Args() हमें ["arg1", "arg2"] की सरणी लौटाता है

हालाँकि कॉलिंग प्रोग्राम arg1 arg2 -flag करता है नहीं जो कुछ भी -flags करना चाहिए उसे टॉगल करता है, और इसके बजाय ["arg1", "arg2", "-flag"] के रूप में स्थिति देता है जिसमें ध्वज होता है पार्स नहीं किया गया था.

यह प्रोग्राम कलराइज़ ls -l जैसे उप-कॉल में पास होने के लिए उपयोगी हो सकता है, जहां ls -l को शाब्दिक रूप से पास किया जाता है - इसलिए मैं उपयोग का मामला देख सकता हूं।

यह सिर्फ इतना है कि अधिकांश कार्यक्रम स्थितिगत वस्तुओं के आसपास कहीं भी ध्वज तर्क की अनुमति देते हैं। ls dir1/ -l dir2/ ls -l dir1/ dir2/ के समान है, और यह एक परंपरा है जो यूनिक्स और लिनक्स कमांड के विशाल बहुमत पर आधारित है।

हो सकता है कि यह आदत डालने लायक चीज़ हो - और आह्वान करने लायक हो।

गो का उद्देश्य और उपयोग का मामला

फ़ाइल आयात प्रतिमान को छोड़कर, मुझे अपना मूल एप्लिकेशन लागू करना बहुत आसान लगा। मैंने जो कुछ भी गलत किया वह बिल्कुल स्पष्ट लगा और त्रुटियाँ अर्थपूर्ण थीं। वास्तव में ऐसा महसूस होता है कि मैं केवल "काम पूरा करने" पर ध्यान केंद्रित कर सकता हूं।

मेरे अब तक के बहुत कम उपयोग से, और मेरी विशिष्ट आवश्यकताओं को ध्यान में रखते हुए, मैं देख सकता हूं

• शुरू करना आसान है
• संकलित बाइनरी, कोई रनटाइम निर्भरता नहीं
• प्रकारों वाली सरल भाषा शेल स्क्रिप्टिंग से एक कदम ऊपर है
• कथित तौर पर आसान मल्टीप्रोसेसिंग समर्थन

मैंने सोचा था कि वस्तुओं और विरासत के बजाय विरल प्रकार रखना एक बाधा होगी, लेकिन अब तक यह अच्छा है। मैं अन्य भाषाओं में उनके बिना ही काम चला लेता हूं, इसलिए मुझे लगता है कि जब मैं इंटरफेस और प्रकारों को परिभाषित करने के करीब पहुंचूंगा, तो यह लुआ और बैश से एक कदम आगे बढ़ने जैसा महसूस होगा। मुझे उम्मीद है।

जिन कारणों से मैं संकलित-से-मूल भाषा का पता लगाना चाहता था, उनमें से एक कारण यह था कि मैं ऐसे बायनेरिज़ का उत्पादन करने में सक्षम हो सकता था, जिन्हें रनटाइम के किसी विशेष संस्करण पर निर्भर होने की आवश्यकता के बिना, आसानी से चारों ओर घुमाया जा सके।

एक सहकर्मी हाल ही में निराश होकर मेरी डेस्क पर आया, और जावा 17 को एक पुरानी नोड बेस छवि पर लाने का प्रयास कर रहा था जो डेबियन 10 पर आधारित थी। या तो उसे एक नई आधार छवि प्राप्त करने के लिए नोड संस्करण को अपग्रेड करना होगा, एक नई डेबियन आधार छवि का उपयोग करना होगा और नोड को मैन्युअल रूप से स्थापित और कॉन्फ़िगर करना होगा, या अच्छाई-जानने वाले के लिए नेकनेस-नोज़-हू द्वारा होस्ट किए गए कस्टम रेपो के लिए इंटरनेट को खंगालना होगा। -यदि जावा 17 को हैक कर लिया गया है जो डेबियन 10 पर चलेगा।

कितना आसान होगा यदि तैनात सॉफ़्टवेयर में ऐसी कोई विरोधाभासी रनटाइम निर्भरता न हो...

ऑप्स के दृष्टिकोण से, एक बड़ा लाभ जो मैं महसूस कर रहा हूं वह यह है कि मैं आसानी से कोड लिख सकता हूं, और एक ईएलएफ बाइनरी बना सकता हूं जिसे फिर "मनमाना सिस्टम एक्स" पर तैनात किया जा सकता है और इसके साथ संघर्ष नहीं करना पड़ेगा यह सुनिश्चित करना कि दिए गए रनटाइम का सही संस्करण मौजूद है, और परस्पर विरोधी निर्भरताओं का प्रबंधन करना।

मुझे यकीन है कि अन्य लाभ भी हैं, और मैंने गो में मल्टीथ्रेडिंग और मल्टीप्रोसेसिंग के उपयोग में आसानी के बारे में बहुत कुछ कहा है, और मैं अगले चरण के रूप में इसका पता लगाने के लिए एक मिनी प्रोजेक्ट तैयार करने का इरादा रखता हूं - संभवतः कुछ ऐसा जो कई चैनलों पर इनपुट सुन सकता है, और प्रतिक्रिया में कुछ बुनियादी कार्य कर सकता है। मेरे पास पहले किए गए कुछ परीक्षण स्वचालन कार्यों में इसका उपयोग-मामला है, इसलिए इस बिंदु पर यह मेरे लिए अलग नहीं है।