हा लेख आधी प्रकाशित झालेल्या एका प्रतिक्रियेला प्रतिसाद म्हणून लिहिला होता antipodean लेख.

गेल्या दोन-अधिक वर्षांमध्ये मी विकसित बिलिंग सिस्टमसह एक विशेष रेडियस सर्व्हर लागू करण्यासाठी Go वापरत आहे. वाटेत, मी स्वतः भाषेची गुंतागुंत शिकत आहे. प्रोग्राम स्वतःच खूप सोपे आहेत आणि या लेखाचा उद्देश नाही, परंतु गो वापरण्याचा अनुभव त्याच्या बचावासाठी काही शब्दांना पात्र आहे. गंभीर, स्केलेबल कोडसाठी गो ही मुख्य प्रवाहातील भाषा बनत आहे. भाषा Google द्वारे तयार केली गेली आहे, जिथे ती सक्रियपणे वापरली जाते. तळाशी ओळ, मला प्रामाणिकपणे वाटते की गो लँग्वेजची रचना अज्ञानी प्रोग्रामरसाठी वाईट आहे.

कमकुवत प्रोग्रामरसाठी डिझाइन केलेले?

दुर्बल लोक समस्यांबद्दल बोलतात. कल्पना आणि स्वप्नांबद्दल जोरदार चर्चा...

गो शिकणे खूप सोपे आहे, इतके सोपे आहे की तुम्ही अक्षरशः कोणत्याही प्रशिक्षणाशिवाय कोड वाचू शकता. भाषेचे हे वैशिष्ट्य बर्‍याच जागतिक कंपन्यांमध्ये वापरले जाते जेव्हा कोड नॉन-कोर तज्ञांसह (व्यवस्थापक, ग्राहक इ.) एकत्र वाचला जातो. डिझाईन ड्रायव्हन डेव्हलपमेंट सारख्या पद्धतींसाठी हे अतिशय सोयीचे आहे.
अगदी नवशिक्या प्रोग्रामर देखील एक किंवा दोन आठवड्यांनंतर बर्‍यापैकी सभ्य कोड तयार करण्यास सुरवात करतात. "गो प्रोग्रामिंग" (मार्क समरफिल्ड द्वारे) मी ज्या पुस्तकातून अभ्यास केला आहे. पुस्तक खूप चांगलं आहे, भाषेच्या अनेक बारीकसारीक गोष्टींना स्पर्श करते. Java, PHP सारख्या अनावश्यक क्लिष्ट भाषांनंतर, जादूची कमतरता ताजेतवाने आहे. परंतु लवकरच किंवा नंतर, बर्याच मर्यादित प्रोग्रामरना नवीन क्षेत्रात जुन्या पद्धती वापरण्याची कल्पना आहे. हे खरोखर आवश्यक आहे का?

रॉब पाईक (भाषेचे मुख्य विचारवंत) यांनी गो भाषा ही औद्योगिक भाषा म्हणून तयार केली जी समजण्यास सोपी आणि वापरण्यास प्रभावी आहे. भाषेची रचना मोठ्या संघांमध्ये जास्तीत जास्त उत्पादकतेसाठी केली गेली आहे आणि त्याबद्दल शंका नाही. अनेक नवशिक्या प्रोग्रामर तक्रार करतात की त्यांच्याकडे अनेक वैशिष्ट्ये नाहीत. साधेपणाची ही इच्छा हा भाषेच्या डिझाइनरचा जाणीवपूर्वक घेतलेला निर्णय होता आणि त्याची गरज का आहे हे पूर्णपणे समजून घेण्यासाठी, विकासकांची प्रेरणा आणि ते Go मध्ये काय साध्य करण्याचा प्रयत्न करत होते हे आपण समजून घेतले पाहिजे.

मग ते इतके सोपे का केले गेले? येथे रॉब पाईकचे दोन कोट्स आहेत:

येथे मुख्य मुद्दा असा आहे की आमचे प्रोग्रामर संशोधक नाहीत. ते, नियमानुसार, अगदी तरुण आहेत, अभ्यास केल्यानंतर आमच्याकडे येतात, कदाचित त्यांनी Java, किंवा C/C++, किंवा Python चा अभ्यास केला असेल. त्यांना उत्तम भाषा समजू शकत नाही, परंतु त्याच वेळी त्यांनी चांगले सॉफ्टवेअर तयार करावे अशी आमची इच्छा आहे. म्हणूनच भाषा समजण्यास व शिकण्यास सोपी असावी.

तो परिचित असावा, अंदाजे सी सारखाच बोलतो. Google वर काम करणारे प्रोग्रामर त्यांचे करिअर लवकर सुरू करतात आणि त्यांना मुख्यतः प्रक्रियात्मक भाषा, विशेषतः C कुटुंबाशी परिचित असतात. नवीन प्रोग्रॅमिंग भाषेत जलद उत्पादनक्षमतेची आवश्यकता म्हणजे भाषा खूप मूलगामी असू नये.

शहाणे शब्द, नाही का?

साधेपणाची कलाकृती

सौंदर्यासाठी साधेपणा ही आवश्यक अट आहे. लेव्ह टॉल्स्टॉय.

हे सोपे ठेवणे हे कोणत्याही डिझाइनमधील सर्वात महत्त्वाचे उद्दिष्ट आहे. तुम्हाला माहिती आहेच की, एक परिपूर्ण प्रकल्प असा प्रकल्प नाही जिथे जोडण्यासारखे काहीही नाही, परंतु ज्यामधून काढण्यासाठी काहीही नाही. बर्‍याच लोकांचा असा विश्वास आहे की जटिल समस्या सोडवण्यासाठी (किंवा अगदी व्यक्त) करण्यासाठी, एक जटिल साधन आवश्यक आहे. मात्र, तसे नाही. उदाहरणार्थ 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);
    }
}

कॉपी करण्याचा नरक

मनुष्य स्वतःमध्ये नरक वाहून नेतो. मार्टिन ल्यूथर.

जेनेरिकच्या कमतरतेच्या बाबतीत नवशिक्या सतत गो बद्दल तक्रार करतात. या समस्येचे निराकरण करण्यासाठी, त्यापैकी बहुतेक थेट कोड कॉपीिंग वापरतात. उदाहरणार्थ, पूर्णांकांच्या सूचीचा सारांश देण्यासाठी फंक्शन, अशा व्यावसायिकांचा असा विश्वास आहे की प्रत्येक डेटा प्रकारासाठी सोप्या कॉपी-पेस्ट करण्याशिवाय कार्यक्षमता इतर कोणत्याही प्रकारे लागू केली जाऊ शकत नाही.

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))
}

आणि, जरी आमचा कोड मागील केसपेक्षा थोडा लांब असल्याचे दिसून आले, तरीही ते सामान्यीकृत झाले आहे. म्हणून, आम्हाला सर्व अंकगणित ऑपरेशन्स अंमलात आणणे कठीण होणार नाही.

बरेच जण म्हणतील की डी मधील प्रोग्राम लक्षणीयपणे लहान दिसतो आणि ते बरोबर असतील.

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 प्रकार आहे. गो भाषा तेच करते.

तोफेपासून चिमण्यांपर्यंत

आणि स्ट्रेटजॅकेट वेडेपणाच्या आकारात फिट असणे आवश्यक आहे. स्टॅनिस्लाव लेक.

बरेच कट्टर चाहते असा दावा करू शकतात की गो कडे जेनेरिक तयार करण्यासाठी आणखी एक यंत्रणा आहे - प्रतिबिंब. आणि ते बरोबर असतील... परंतु केवळ क्वचित प्रसंगी.

रॉब पाईक आम्हाला चेतावणी देतो:

हे एक शक्तिशाली साधन आहे जे सावधगिरीने वापरले पाहिजे. कठोरपणे आवश्यक नसल्यास ते टाळले पाहिजे.

विकिपीडिया आम्हाला खालील गोष्टी सांगतो:

रिफ्लेक्शन म्हणजे त्या प्रक्रियेचा संदर्भ आहे ज्या दरम्यान एक प्रोग्राम त्याच्या स्वत: च्या रचना आणि वर्तनाचे परीक्षण आणि सुधारणा करू शकतो. प्रोग्रामिंग पॅराडाइम अंतर्निहित प्रतिबिंब याला प्रतिबिंबित प्रोग्रामिंग म्हणतात. हा मेटाप्रोग्रामिंगचा एक प्रकार आहे.

तथापि, आपल्याला माहिती आहे की, आपल्याला प्रत्येक गोष्टीसाठी पैसे द्यावे लागतील. या प्रकरणात ते आहे:

• कार्यक्रम लिहिण्यात अडचण
• कार्यक्रम अंमलबजावणी गती

म्हणून, मोठ्या-कॅलिबर शस्त्राप्रमाणे, प्रतिबिंब सावधगिरीने वापरणे आवश्यक आहे. परावर्तनाचा अविचारी वापर केल्याने न वाचता येणारे प्रोग्राम्स, सतत चुका आणि वेग कमी होतो. स्नॉब प्रोग्रामरला त्याचा कोड इतर, अधिक व्यावहारिक आणि विनम्र सहकाऱ्यांसमोर दाखवण्यात सक्षम असणे हीच गोष्ट आहे.

शीकडून सांस्कृतिक सामान? नाही, अनेक भाषांमधून!

नशिबाबरोबरच वारसांवर कर्जही सोडले जाते.

भाषा पूर्णपणे सी वारशावर आधारित आहे असा अनेकांचा विश्वास असूनही, असे नाही. भाषा सर्वोत्तम प्रोग्रामिंग भाषांच्या अनेक पैलूंचा समावेश करते.

वाक्यरचना

सर्व प्रथम, व्याकरणाच्या रचनांची वाक्यरचना सी भाषेच्या वाक्यरचनेवर आधारित आहे. तथापि, डेल्फी भाषेचा देखील लक्षणीय प्रभाव होता. अशा प्रकारे, आपण पाहतो की प्रोग्रामची वाचनीयता मोठ्या प्रमाणात कमी करणारे अनावश्यक कंस पूर्णपणे काढून टाकले गेले आहेत. भाषेमध्ये DELPHI भाषेचा अंतर्निहित “:=” ऑपरेटर देखील आहे. पॅकेजेसची संकल्पना ADA सारख्या भाषांमधून घेतली आहे. न वापरलेल्या घटकांची घोषणा PROLOG भाषेतून घेतली आहे.

शब्दार्थ

पॅकेज डेल्फी भाषेच्या शब्दार्थावर आधारित होते. प्रत्येक पॅकेज डेटा आणि कोड एन्कॅप्स्युलेट करते आणि त्यात खाजगी आणि सार्वजनिक संस्था असतात. हे तुम्हाला पॅकेज इंटरफेस कमीतकमी कमी करण्यास अनुमती देते.

डेलिगेशन पद्धतीने अंमलबजावणीची कार्यवाही DELPHI भाषेतून घेण्यात आली.

संकलन

हे विनाकारण नाही की एक विनोद आहे: सी प्रोग्राम संकलित केला जात असताना गो विकसित केला गेला. भाषेचे एक बलस्थान म्हणजे तिचे अति-जलद संकलन. ही कल्पना DELPHI भाषेतून घेतली होती. प्रत्येक गो पॅकेज डेल्फी मॉड्यूलशी संबंधित आहे. जेव्हा खरोखर आवश्यक असेल तेव्हाच ही पॅकेजेस पुन्हा संकलित केली जातात. त्यामुळे, पुढील संपादनानंतर, तुम्हाला संपूर्ण प्रोग्राम संकलित करण्याची गरज नाही, तर केवळ बदललेली पॅकेजेस आणि पॅकेजेस पुन्हा संकलित करा जी या बदललेल्या पॅकेजेसवर अवलंबून आहेत (आणि तरीही, पॅकेज इंटरफेस बदलले असल्यासच).

उच्च-स्तरीय बांधकामे

भाषेमध्ये अनेक भिन्न उच्च-स्तरीय रचना आहेत ज्या C सारख्या निम्न-स्तरीय भाषांशी संबंधित नाहीत.

• तार
• हॅश टेबल
• काप
• डक टायपिंग RUBY सारख्या भाषांमधून उधार घेतले जाते (जे, दुर्दैवाने, अनेकांना समजत नाही किंवा त्याच्या पूर्ण क्षमतेने वापरता येत नाही).

मेमरी व्यवस्थापन

मेमरी मॅनेजमेंट साधारणपणे वेगळ्या लेखाला पात्र आहे. C++ सारख्या भाषांमध्ये, नियंत्रण पूर्णपणे विकसकाकडे सोडल्यास, नंतर DELPHI सारख्या भाषांमध्ये, संदर्भ मोजणी मॉडेल वापरले गेले. या दृष्टिकोनासह, चक्रीय संदर्भांना परवानगी नव्हती, कारण अनाथ क्लस्टर तयार झाले होते, त्यानंतर Go ने अशा क्लस्टर्सचा अंतर्निहित शोध घेतला आहे (जसे C#). याव्यतिरिक्त, कचरा संकलक हे सध्याच्या ज्ञात अंमलबजावणीपेक्षा अधिक कार्यक्षम आहे आणि ते आधीच अनेक रिअल-टाइम कार्यांसाठी वापरले जाऊ शकते. स्टॅकवर व्हेरिएबल संचयित करण्यासाठी मूल्य वाटप केले जाऊ शकते तेव्हा भाषा स्वतः परिस्थिती ओळखते. यामुळे मेमरी मॅनेजरवरील भार कमी होतो आणि प्रोग्रामचा वेग वाढतो.

समरूपता आणि समरूपता

भाषेची समांतरता आणि स्पर्धात्मकता कौतुकाच्या पलीकडे आहे. कोणतीही निम्न-स्तरीय भाषा दूरस्थपणे Go शी स्पर्धा करू शकत नाही. प्रामाणिकपणे, हे लक्षात घेण्यासारखे आहे की मॉडेल भाषेच्या लेखकांनी शोधले नव्हते, परंतु ते फक्त जुन्या एडीए भाषेतून घेतले होते. बहु-थ्रेडेड कोडसाठी वैशिष्ट्यपूर्ण डेडलॉक आणि शर्यतीच्या परिस्थितीसह परिमाण कमी जटिल समस्या असताना, भाषा सर्व CPUs वापरून लाखो समांतर कनेक्शनवर प्रक्रिया करण्यास सक्षम आहे.

अतिरिक्त फायदे

जर ते फायदेशीर असेल तर प्रत्येकजण निस्वार्थी होईल.

भाषा आम्हाला अनेक निःसंशय फायदे देखील प्रदान करते:

• प्रकल्प तयार केल्यानंतर एकच एक्झिक्यूटेबल फाइल अनुप्रयोगांची तैनाती मोठ्या प्रमाणात सुलभ करते.
• स्टॅटिक टायपिंग आणि टाईप इन्फरन्स तुमच्या कोडमधील त्रुटींची संख्या लक्षणीयरीत्या कमी करू शकतात, अगदी चाचण्या लिहिल्याशिवाय. मला काही प्रोग्रामर माहित आहेत जे अजिबात चाचण्या लिहिल्याशिवाय करतात आणि त्यांच्या कोडच्या गुणवत्तेला फारसा त्रास होत नाही.
• अत्यंत साधे क्रॉस-कंपिलेशन आणि मानक लायब्ररीची उत्कृष्ट पोर्टेबिलिटी, जी क्रॉस-प्लॅटफॉर्म ऍप्लिकेशन्सचा विकास मोठ्या प्रमाणात सुलभ करते.
• RE2 रेग्युलर एक्सप्रेशन्स थ्रेड-सेफ आहेत आणि त्यांच्या अंमलबजावणीच्या वेळेचा अंदाज आहे.
• एक शक्तिशाली मानक लायब्ररी जी बहुतेक प्रकल्पांना तृतीय-पक्ष फ्रेमवर्कशिवाय करू देते.
• समस्या कशी सोडवायची यापेक्षा त्यावर लक्ष केंद्रित करण्यासाठी भाषा पुरेशी शक्तिशाली आहे, तरीही समस्या प्रभावीपणे सोडवता येण्याइतकी निम्न-स्तरीय आहे.
• गो इको सिस्टीममध्ये आधीपासूनच सर्व प्रसंगांसाठी विकसित साधने आहेत: चाचण्या, दस्तऐवजीकरण, पॅकेज व्यवस्थापन, शक्तिशाली लिंटर्स, कोड जनरेशन, रेस कंडिशन डिटेक्टर इ.
• गो आवृत्ती 1.11 ने बिल्ट-इन सिमेंटिक अवलंबित्व व्यवस्थापन सादर केले आहे, जे लोकप्रिय VCS होस्टिंगच्या शीर्षस्थानी तयार केले आहे. गो इकोसिस्टम बनवणारी सर्व साधने या सेवांचा वापर त्यांच्याकडून कोड डाउनलोड, बिल्ड आणि इन्स्टॉल करण्यासाठी एकाच वेळी करतात. आणि ते छान आहे. आवृत्ती 1.11 च्या आगमनाने, पॅकेज आवृत्तीची समस्या देखील पूर्णपणे निराकरण झाली.
• कारण भाषेची मूळ कल्पना जादू कमी करणे आहे, भाषा विकासकांना स्पष्टपणे त्रुटी हाताळण्यासाठी प्रोत्साहन देते. आणि हे बरोबर आहे, कारण अन्यथा, ते पूर्णपणे त्रुटी हाताळण्याबद्दल विसरून जाईल. दुसरी गोष्ट अशी आहे की बहुतेक डेव्हलपर त्रुटी हाताळण्याकडे जाणीवपूर्वक दुर्लक्ष करतात, एरर वरच्या दिशेने पुढे पाठवण्याऐवजी त्यांच्यावर प्रक्रिया करण्याऐवजी प्राधान्य देतात.
• भाषा शास्त्रीय OOP पद्धती लागू करत नाही, कारण तिच्या शुद्ध स्वरूपात Go मध्ये कोणतीही आभासीता नाही. तथापि, इंटरफेस वापरताना ही समस्या नाही. OOP च्या अनुपस्थितीमुळे नवशिक्यांसाठी प्रवेशाचा अडथळा लक्षणीयरीत्या कमी होतो.

समाजाच्या फायद्यासाठी साधेपणा

गुंतागुंत करणे सोपे आहे, सोपे करणे कठीण आहे.

Go ची रचना सोपी करण्यासाठी केली गेली होती आणि ती त्या ध्येयात यशस्वी होते. हे अशा स्मार्ट प्रोग्रामरसाठी लिहिले गेले आहे जे टीमवर्कचे फायदे समजतात आणि एंटरप्राइझ-स्तरीय भाषांच्या अंतहीन परिवर्तनशीलतेमुळे कंटाळले आहेत. त्याच्या शस्त्रागारात सिंटॅक्टिक स्ट्रक्चर्सचा तुलनेने लहान संच असल्याने, ते व्यावहारिकरित्या काळानुसार बदलांच्या अधीन नाही, म्हणून विकसकांना विकासासाठी बराच वेळ मोकळा आहे, आणि भाषेच्या नवकल्पनांचा सतत अभ्यास करण्यासाठी नाही.

कंपन्यांना अनेक फायदे देखील मिळतात: कमी प्रवेशाचा अडथळा त्यांना त्वरीत तज्ञ शोधू देतो आणि भाषेची अपरिवर्तनीयता त्यांना 10 वर्षांनंतरही समान कोड वापरण्याची परवानगी देते.

निष्कर्ष

मोठ्या मेंदूच्या आकारामुळे कधीही कोणत्याही हत्तीला नोबेल पारितोषिक मिळालेले नाही.

ज्या प्रोग्रामरचा वैयक्तिक अहंकार सांघिक भावनेपेक्षा प्राधान्य घेतो, तसेच शैक्षणिक आव्हाने आणि अंतहीन "स्व-सुधारणा" आवडते अशा सिद्धांतकारांसाठी, भाषा खरोखरच वाईट आहे, कारण ती एक सामान्य-उद्देशीय कलाकृती भाषा आहे जी तुम्हाला मिळवू देत नाही. तुमच्या कामाच्या परिणामातून सौंदर्याचा आनंद आणि सहकाऱ्यांसमोर स्वत:ला व्यावसायिक दाखवा (आम्ही या निकषांनुसार बुद्धिमत्ता मोजतो, IQ नुसार नाही). जीवनातील प्रत्येक गोष्टीप्रमाणे, ही वैयक्तिक प्राधान्यांची बाब आहे. सर्व सार्थक नवकल्पनांप्रमाणेच, भाषाही सार्वत्रिक नकारापासून मोठ्या प्रमाणावर स्वीकारापर्यंत खूप पुढे गेली आहे. भाषा त्याच्या साधेपणामध्ये कल्पक आहे आणि, जसे तुम्हाला माहिती आहे, कल्पक सर्वकाही सोपे आहे!

स्त्रोत: www.habr.com