სტატია დაიწერა, როგორც პასუხი ადრე გამოქვეყნებულზე ანტიპოდური სტატია.

ბოლო ორი და მეტი წლის განმავლობაში მე ვიყენებდი Go-ს სპეციალიზებული RADIUS სერვერის დასანერგად, განვითარებული ბილინგის სისტემით. გზაში მე ვსწავლობ თავად ენის სირთულეებს. თავად პროგრამები ძალიან მარტივია და არ არის ამ სტატიის მიზანი, მაგრამ Go-ს გამოყენების გამოცდილება თავისთავად იმსახურებს რამდენიმე სიტყვას მის დასაცავად. Go ხდება მზარდი ძირითადი ენა სერიოზული, მასშტაბირებადი კოდისთვის. ენა შეიქმნა Google-ის მიერ, სადაც ის აქტიურად გამოიყენება. დედააზრი, გულწრფელად ვფიქრობ, რომ Go ენის დიზაინი ცუდია არაინტელექტუალური პროგრამისტებისთვის.

შექმნილია სუსტი პროგრამისტებისთვის?

სუსტები პრობლემებზე საუბრობენ. ძლიერი საუბარი იდეებზე და ოცნებებზე...

Go-ის სწავლა ძალიან მარტივია, იმდენად მარტივია, რომ კოდის წაკითხვა შეგიძლიათ პრაქტიკულად ვარჯიშის გარეშე. ენის ეს თვისება გამოიყენება ბევრ გლობალურ კომპანიაში, როდესაც კოდი იკითხება არა ძირითად სპეციალისტებთან ერთად (მენეჯერები, მომხმარებლები და ა.შ.). ეს ძალიან მოსახერხებელია ისეთი მეთოდოლოგიებისთვის, როგორიცაა დიზაინი ორიენტირებული განვითარება.
დამწყები პროგრამისტებიც კი იწყებენ საკმაოდ წესიერი კოდის წარმოებას ერთი-ორი კვირის შემდეგ. წიგნი, საიდანაც ვსწავლობდი არის "Go Programming" (Mark Summerfield). წიგნი ძალიან კარგია, ენის ბევრ ნიუანსს ეხება. ზედმეტად რთული ენების შემდეგ, როგორიცაა Java, PHP, მაგიის ნაკლებობა განაახლებს. მაგრამ ადრე თუ გვიან, ბევრ შეზღუდულ პროგრამისტს უჩნდება იდეა გამოიყენოს ძველი მეთოდები ახალ სფეროში. ეს ნამდვილად აუცილებელია?

რობ პაიკმა (ენის მთავარმა იდეოლოგმა) შექმნა Go ენა, როგორც ინდუსტრიული ენა, რომელიც ადვილად გასაგები და ეფექტური გამოსაყენებელია. ენა შექმნილია დიდ გუნდებში მაქსიმალური პროდუქტიულობისთვის და ამაში ეჭვი არ ეპარება. ბევრი დამწყები პროგრამისტი ჩივის, რომ ბევრი ფუნქცია აკლია. სიმარტივის ეს სურვილი ენის დიზაინერების შეგნებული გადაწყვეტილება იყო და იმისათვის, რომ სრულად გავიგოთ, რატომ იყო ეს საჭირო, უნდა გვესმოდეს დეველოპერების მოტივაცია და რის მიღწევას ცდილობდნენ Go-ში.

რატომ გაკეთდა ასე მარტივი? აქ არის რამოდენიმე ციტატა რობ პაიკისგან:

აქ მთავარი ის არის, რომ ჩვენი პროგრამისტები არ არიან მკვლევარები. ისინი, როგორც წესი, საკმაოდ ახალგაზრდები არიან, ჩვენთან სწავლის შემდეგ მოდიან, ალბათ Java-ს სწავლობდნენ, ან C/C++-ს, ან პითონს. მათ არ ესმით შესანიშნავი ენა, მაგრამ ამავე დროს ჩვენ გვინდა, რომ მათ შექმნან კარგი პროგრამული უზრუნველყოფა. ამიტომ ენა ადვილად გასაგები და შესასწავლი უნდა იყოს.

ის უნდა იყოს ნაცნობი, უხეშად რომ ვთქვათ C-ის მსგავსი. Google-ში მომუშავე პროგრამისტები კარიერას ადრე იწყებენ და ძირითადად იცნობენ პროცედურულ ენებს, განსაკუთრებით C ოჯახს. ახალი პროგრამირების ენაში სწრაფი პროდუქტიულობის მოთხოვნა ნიშნავს, რომ ენა არ უნდა იყოს ძალიან რადიკალური.

ბრძნული სიტყვები, არა?

სიმარტივის არტეფაქტები

სიმარტივე სილამაზის აუცილებელი პირობაა. ლევ ტოლსტოი.

სიმარტივის შენარჩუნება ერთ-ერთი ყველაზე მნიშვნელოვანი მიზანია ნებისმიერ დიზაინში. მოგეხსენებათ, სრულყოფილი პროექტი არ არის პროექტი, სადაც დასამატებელი არაფერია, არამედ ის, საიდანაც არაფერია მოსახსნელი. ბევრს სჯერა, რომ რთული პრობლემების გადასაჭრელად (ან თუნდაც გამოხატვას) რთული ინსტრუმენტია საჭირო. თუმცა, ეს ასე არ არის. მაგალითად ავიღოთ PERL ენა. ენის იდეოლოგები თვლიდნენ, რომ პროგრამისტს უნდა ჰქონდეს მინიმუმ სამი განსხვავებული გზა ერთი პრობლემის გადასაჭრელად. Go-ის ენის იდეოლოგებმა სხვა გზა აიღეს, მათ გადაწყვიტეს, რომ მიზნის მისაღწევად ერთი, მაგრამ მართლაც კარგი გზა საკმარისი იყო. ამ მიდგომას სერიოზული საფუძველი აქვს: ერთადერთი გზა არის ადვილი სწავლა და უფრო რთული დავიწყება.

ბევრი მიგრანტი ჩივის, რომ ენა არ შეიცავს ელეგანტურ აბსტრაქციას. დიახ, ეს მართალია, მაგრამ ეს არის ენის ერთ-ერთი მთავარი უპირატესობა. ენა შეიცავს მინიმუმ მაგიას - ამიტომ პროგრამის წასაკითხად არ არის საჭირო ღრმა ცოდნა. რაც შეეხება კოდის სიტყვიერებას, ეს საერთოდ არ არის პრობლემა. კარგად დაწერილი Golang პროგრამა იკითხება ვერტიკალურად, მცირე ან სტრუქტურის გარეშე. გარდა ამისა, პროგრამის წაკითხვის სიჩქარე მინიმუმ ბრძანებით აღემატება მისი ჩაწერის სიჩქარეს. თუ თვლით, რომ ყველა კოდს აქვს ერთიანი ფორმატირება (შესრულებულია ჩაშენებული gofmt ბრძანების გამოყენებით), მაშინ რამდენიმე დამატებითი ხაზის წაკითხვა საერთოდ არ არის პრობლემა.

არ არის ძალიან ექსპრესიული

ხელოვნება არ მოითმენს, როცა მისი თავისუფლება შეზღუდულია. სიზუსტე არ არის მისი პასუხისმგებლობა.

სიმარტივის სურვილის გამო, Go-ს აკლია კონსტრუქტები, რომლებიც სხვა ენებში აღიქმება როგორც რაღაც ბუნებრივად მათთვის მიჩვეული ადამიანების მიერ. თავდაპირველად ეს შეიძლება გარკვეულწილად მოუხერხებელი იყოს, მაგრამ შემდეგ შეამჩნევთ, რომ პროგრამა ბევრად უფრო ადვილი და ცალსახა წასაკითხია.

მაგალითად, კონსოლის პროგრამა, რომელიც კითხულობს 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)
}

იგივე პრობლემის გადაწყვეტა D-ში, თუმცა ის გარკვეულწილად მოკლედ გამოიყურება, იოლი წასაკითხი არ არის

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

თუმცა, ეს მხოლოდ უფრო მოკლეა, მაგრამ არა უფრო სწორი, რადგან D განხორციელება მთლიანად უგულებელყოფს შეცდომების დამუშავების პრობლემას.

რეალურ ცხოვრებაში, როგორც ლოგიკის სირთულე იზრდება, უფსკრული სწრაფად ვიწროვდება. უფსკრული კიდევ უფრო სწრაფად იხურება, როდესაც თქვენ გჭირდებათ ისეთი მოქმედების შესრულება, რომლის შესრულებაც შეუძლებელია სტანდარტული ენის ოპერატორების გამოყენებით.

შენარჩუნების, გაფართოების და წაკითხვის კუთხით, ჩემი აზრით, Go ენა იმარჯვებს, თუმცა ის კარგავს სიტყვიერებაში.

განზოგადებული პროგრამირება ზოგიერთ შემთხვევაში გვაძლევს უდავო სარგებელს. ეს აშკარად ილუსტრირებულია დახარისხების პაკეტით. ასე რომ, ნებისმიერი სიის დასალაგებლად, უბრალოდ უნდა განვახორციელოთ 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 ბრძანება, ნახავთ, რამდენად ხშირად გამოიყენება დამაბნეველი ინტერფეისები. ახლობელი ამხანაგები მაშინვე იტყვიან, რომ ეს ყველაფერი ჯენერიკების ნაკლებობითაა განპირობებული. თუმცა, ეს ყოველთვის ასე არ არის. მაგალითისთვის ავიღოთ DELPHI. იმავე გენერიკების არსებობის მიუხედავად, ის შეიცავს სპეციალურ VARIANT ტიპს ოპერაციებისთვის თვითნებური მონაცემთა ტიპებით. Go ენაც იგივეს აკეთებს.

თოფიდან ბეღურებამდე

და სტრიქონი უნდა შეესაბამებოდეს სიგიჟის ზომას. სტანისლავ ლეკი.

ბევრი ექსტრემალური ფანი შეიძლება ამტკიცებდეს, რომ Go-ს აქვს გენერიკების შექმნის კიდევ ერთი მექანიზმი - რეფლექსია. და მართლები იქნებიან... მაგრამ მხოლოდ იშვიათ შემთხვევებში.

რობ პაიკი გვაფრთხილებს:

ეს არის ძლიერი ინსტრუმენტი, რომელიც უნდა იქნას გამოყენებული სიფრთხილით. ეს თავიდან უნდა იქნას აცილებული, გარდა იმ შემთხვევისა, როდესაც მკაცრად ეს აუცილებელია.

ვიკიპედია გვეუბნება შემდეგს:

ასახვა ეხება პროცესს, რომლის დროსაც პროგრამას შეუძლია მონიტორინგი და შეცვალოს საკუთარი სტრუქტურა და ქცევა შესრულების დროს. პროგრამირების პარადიგმას, რომელიც ემყარება ასახვას, ეწოდება ამრეკლავი პროგრამირება. ეს არის მეტაპროგრამირების ტიპი.

თუმცა, როგორც მოგეხსენებათ, ყველაფრის გადახდა მოგიწევთ. ამ შემთხვევაში ეს არის:

• პროგრამების წერის სირთულე
• პროგრამის შესრულების სიჩქარე

ამიტომ, არეკვლა სიფრთხილით უნდა იქნას გამოყენებული, როგორც დიდი კალიბრის იარაღი. ასახვის დაუფიქრებელი გამოყენება იწვევს წაუკითხავ პროგრამებს, მუდმივ შეცდომებს და დაბალ სიჩქარეს. უბრალოდ, სნობ პროგრამისტმა შეძლოს თავისი კოდის წარმოჩენა სხვა, უფრო პრაგმატული და მოკრძალებული კოლეგების წინაშე.

კულტურული ბარგი Xi-დან? არა, რამდენიმე ენიდან!

სიმდიდრესთან ერთად მემკვიდრეებს ვალებიც უტოვებენ.

მიუხედავად იმისა, რომ ბევრი თვლის, რომ ენა მთლიანად დაფუძნებულია C მემკვიდრეობაზე, ეს ასე არ არის. ენა აერთიანებს საუკეთესო პროგრამირების ენების ბევრ ასპექტს.

სინტაქსი

უპირველეს ყოვლისა, გრამატიკული სტრუქტურების სინტაქსი ეფუძნება C ენის სინტაქსს. თუმცა, DELPHI ენასაც მნიშვნელოვანი გავლენა ჰქონდა. ამრიგად, ჩვენ ვხედავთ, რომ ზედმეტი ფრჩხილები, რომლებიც მნიშვნელოვნად ამცირებს პროგრამის წაკითხვას, მთლიანად ამოღებულია. ენა ასევე შეიცავს ":=" ოპერატორს, რომელიც თან ახლავს DELPHI ენას. პაკეტების კონცეფცია ნასესხებია ისეთი ენებიდან, როგორიცაა ADA. გამოუყენებელი ერთეულების დეკლარაცია ნასესხებია PROLOG ენიდან.

სემანტიკა

პაკეტები დაფუძნებული იყო DELPHI ენის სემანტიკაზე. თითოეული პაკეტი შეიცავს მონაცემებსა და კოდს და შეიცავს კერძო და საჯარო პირებს. ეს საშუალებას გაძლევთ შეამციროთ პაკეტის ინტერფეისი მინიმუმამდე.

განხორციელების ოპერაცია დელეგაციის მეთოდით ნასესხები იყო DELPHI ენიდან.

შედგენა

უსაფუძვლოდ არ არის ხუმრობა: Go შეიქმნა C პროგრამის შედგენის დროს. ენის ერთ-ერთი ძლიერი მხარე მისი ულტრა სწრაფი შედგენაა. იდეა ნასესხები იყო DELPHI ენიდან. თითოეული Go პაკეტი შეესაბამება DELPHI მოდულს. ეს პაკეტები ხელახლა შედგენილია მხოლოდ მაშინ, როდესაც ნამდვილად საჭიროა. ამიტომ, შემდეგი რედაქტირების შემდეგ, თქვენ არ გჭირდებათ მთელი პროგრამის შედგენა, არამედ მხოლოდ შეცვლილი პაკეტებისა და პაკეტების ხელახლა შედგენა, რომლებიც დამოკიდებულია ამ შეცვლილ პაკეტებზე (და მაშინაც კი, მხოლოდ იმ შემთხვევაში, თუ პაკეტის ინტერფეისები შეიცვალა).

მაღალი დონის კონსტრუქციები

ენა შეიცავს ბევრ სხვადასხვა მაღალი დონის კონსტრუქტს, რომლებიც არანაირად არ არის დაკავშირებული დაბალი დონის ენებთან, როგორიცაა C.

• სიმები
• ჰაში მაგიდები
• ნაჭრები
• იხვის აკრეფა ნასესხებია ისეთი ენებიდან, როგორიცაა RUBY (რომელიც, სამწუხაროდ, ბევრს არ ესმის ან არ იყენებს მის სრულ პოტენციალს).

მეხსიერების მართვა

მეხსიერების მართვა ზოგადად იმსახურებს ცალკე სტატიას. თუ ისეთ ენებში, როგორიცაა C++, კონტროლი მთლიანად დეველოპერს ეკუთვნის, შემდეგ ენებზე, როგორიცაა DELPHI, გამოყენებული იქნა მითითების დათვლის მოდელი. ამ მიდგომით, ციკლური მითითებები არ იყო დაშვებული, რადგან ჩამოყალიბდა ობოლი კლასტერები, შემდეგ Go-ს აქვს ჩაშენებული ასეთი კლასტერების გამოვლენა (როგორიცაა C#). გარდა ამისა, ნაგვის შემგროვებელი უფრო ეფექტურია, ვიდრე ამჟამად ცნობილი განხორციელებები და უკვე შეიძლება გამოყენებულ იქნას რეალურ დროში მრავალი ამოცანისთვის. ენა თავად ცნობს სიტუაციებს, როდესაც ცვლადის შესანახი მნიშვნელობა შეიძლება გამოყოფილი იყოს სტეკზე. ეს ამცირებს მეხსიერების მენეჯერის დატვირთვას და ზრდის პროგრამის სიჩქარეს.

კონკურენტულობა და კონკურენტულობა

ენის პარალელურობა და კონკურენტუნარიანობა ქებას მიღმაა. არც ერთი დაბალი დონის ენა ვერც კი დისტანციურად გაუწევს კონკურენციას Go-ს. სამართლიანობისთვის, უნდა აღინიშნოს, რომ მოდელი არ არის გამოგონილი ენის ავტორების მიერ, არამედ უბრალოდ ნასესხებია ძველი კარგი ADA ენიდან. ენას შეუძლია მილიონობით პარალელური კავშირის დამუშავება ყველა CPU-ის გამოყენებით, ამასთან, აქვს სიდიდის ნაკლები კომპლექსური პრობლემები ჩიხებთან და რასის პირობებში, რომლებიც დამახასიათებელია მრავალნაკადიანი კოდისთვის.

დამატებითი სარგებელი

თუ ეს მომგებიანია, ყველა უანგარო გახდება.

ენა ასევე გვაძლევს უამრავ უდავო სარგებელს:

• პროექტის შექმნის შემდეგ ერთი შესრულებადი ფაილი მნიშვნელოვნად ამარტივებს აპლიკაციების განლაგებას.
• სტატიკური აკრეფით და ტიპის დასკვნამ შეიძლება მნიშვნელოვნად შეამციროს შეცდომების რაოდენობა თქვენს კოდში, თუნდაც ტესტების ჩაწერის გარეშე. მე ვიცნობ რამდენიმე პროგრამისტს, რომლებიც საერთოდ არ წერენ ტესტებს და მათი კოდის ხარისხი მნიშვნელოვნად არ დაზარალდება.
• სტანდარტული ბიბლიოთეკის ძალიან მარტივი კროს-კომპილაცია და შესანიშნავი პორტაბელურობა, რაც მნიშვნელოვნად ამარტივებს კროს-პლატფორმული აპლიკაციების შემუშავებას.
• RE2 რეგულარული გამონათქვამები უსაფრთხოა ძაფებში და აქვთ შესრულების პროგნოზირებადი დრო.
• მძლავრი სტანდარტული ბიბლიოთეკა, რომელიც საშუალებას აძლევს პროექტების უმეტესობას გააკეთონ მესამე მხარის ჩარჩოების გარეშე.
• ენა საკმარისად ძლიერია იმისთვის, რომ ყურადღება გაამახვილოს პრობლემაზე და არა მის გადაჭრაზე, მაგრამ საკმარისად დაბალი დონისაა, რომ პრობლემა ეფექტურად გადაწყდეს.
• Go eco სისტემა უკვე შეიცავს განვითარებულ ინსტრუმენტებს ყველა შემთხვევისთვის: ტესტები, დოკუმენტაცია, პაკეტის მართვა, მძლავრი ლინტერები, კოდის გენერირება, რასის პირობების დეტექტორი და ა.შ.
• Go ვერსია 1.11-მა შემოიღო ჩაშენებული სემანტიკური დამოკიდებულების მენეჯმენტი, რომელიც აგებულია პოპულარული VCS ჰოსტინგის თავზე. ყველა ინსტრუმენტი, რომელიც ქმნის Go ეკოსისტემას, იყენებს ამ სერვისებს, რათა ჩამოტვირთოს, შექმნან და დააინსტალირონ მათგან კოდი ერთი დარტყმით. და ეს მშვენიერია. 1.11 ვერსიის მოსვლით, პაკეტის ვერსიების პრობლემაც მთლიანად მოგვარდა.
• იმის გამო, რომ ენის ძირითადი იდეა არის მაგიის შემცირება, ენა ასტიმულირებს დეველოპერებს შეცდომების მკაფიოდ დამუშავებისკენ. და ეს სწორია, რადგან წინააღმდეგ შემთხვევაში, ის უბრალოდ დაივიწყებს შეცდომების დამუშავებას. კიდევ ერთი რამ არის ის, რომ დეველოპერების უმეტესობა შეგნებულად უგულებელყოფს შეცდომებს და ამჯობინებს მათი დამუშავების ნაცვლად უბრალოდ გადააგზავნოს შეცდომის ზემოთ.
• ენა არ ახორციელებს კლასიკურ OOP მეთოდოლოგიას, რადგან მისი სუფთა სახით არ არსებობს ვირტუალურობა Go-ში. თუმცა, ეს არ არის პრობლემა ინტერფეისების გამოყენებისას. OOP-ის არარსებობა მნიშვნელოვნად ამცირებს დამწყებთათვის შესვლის ბარიერს.

სიმარტივე საზოგადოების სარგებლისთვის

ადვილი გასართულებელია, რთული გასამარტივებელი.

Go შექმნილია იმისათვის, რომ იყოს მარტივი და ის ამ მიზანს აღწევს. იგი დაიწერა ჭკვიანი პროგრამისტებისთვის, რომლებსაც ესმით გუნდური მუშაობის უპირატესობები და დაიღალნენ Enterprise-ის დონის ენების გაუთავებელი ცვალებადობით. სინტაქსური სტრუქტურების შედარებით მცირე ნაკრების არსენალში, იგი პრაქტიკულად არ ექვემდებარება ცვლილებებს დროთა განმავლობაში, ამიტომ დეველოპერებს აქვთ ბევრი დრო გამოთავისუფლებული განვითარებისთვის და არა ენის ინოვაციების უსასრულო შესწავლისთვის.

კომპანიები ასევე იღებენ უამრავ უპირატესობას: შესვლის დაბალი ბარიერი მათ საშუალებას აძლევს სწრაფად იპოვონ სპეციალისტი, ხოლო ენის უცვლელობა მათ საშუალებას აძლევს გამოიყენონ იგივე კოდი 10 წლის შემდეგაც კი.

დასკვნა

ტვინის დიდმა ზომამ არასოდეს გახადა არც ერთი სპილო ნობელის პრემიის ლაურეატი.

იმ პროგრამისტებისთვის, რომელთა პიროვნული ეგო პრიორიტეტულია გუნდურ სულზე, ისევე როგორც თეორეტიკოსებისთვის, რომლებსაც უყვართ აკადემიური გამოწვევები და გაუთავებელი „თვითგანვითარება“, ენა ნამდვილად ცუდია, რადგან ეს არის ზოგადი დანიშნულების ხელოსნური ენა, რომელიც არ გაძლევთ საშუალებას მიიღოთ ესთეტიკური სიამოვნება თქვენი მუშაობის შედეგიდან და გამოიჩინეთ თავი პროფესიონალურად კოლეგების წინაშე (იმ პირობით, რომ ინტელექტს გავზომოთ ამ კრიტერიუმებით და არა IQ-ით). როგორც ყველაფერი ცხოვრებაში, ესეც პიროვნული პრიორიტეტების საკითხია. ყველა ღირებული ინოვაციის მსგავსად, ენამ უკვე გაიარა დიდი გზა საყოველთაო უარყოფიდან მასობრივ მიღებამდე. ენა თავისი სიმარტივით გენიალურია და, მოგეხსენებათ, ყველაფერი ეშმაკური მარტივია!

წყარო: www.habr.com