Статията е написана като отговор на публикувана по-рано антиподна статия.

През последните две и повече години използвах Go за внедряване на специализиран RADIUS сървър с развита система за таксуване. По пътя научавам тънкостите на самия език. Самите програми са много прости и не са целта на тази статия, но самото изживяване от използването на Go заслужава няколко думи в своя защита. Go става все по-масов език за сериозен, мащабируем код. Езикът е създаден от Google, където се използва активно. В крайна сметка, честно казано смятам, че дизайнът на езика Go е лош за НЕинтелигентните програмисти.

Предназначен за слаби програмисти?

Слабите говорят за проблеми. Силният разговор за идеи и мечти...

Go е много лесен за научаване, толкова лесен, че можете да прочетете кода без почти никакво обучение. Тази функция на езика се използва в много световни компании, когато кодът се чете заедно с неосновни специалисти (мениджъри, клиенти и т.н.). Това е много удобно за методологии като Design Driven Development.
Дори начинаещите програмисти започват да произвеждат доста приличен код след седмица или две. Книгата, по която учих, е „Програмиране“ (от Марк Съмърфийлд). Книгата е много добра, засяга много нюанси на езика. След ненужно сложни езици като Java, PHP, липсата на магия е освежаваща. Но рано или късно много ограничени програмисти имат идеята да използват стари методи в нова област. Това наистина ли е необходимо?

Роб Пайк (основният идеолог на езика) създаде езика Go като индустриален език, който е лесен за разбиране и ефективен за използване. Езикът е създаден за максимална продуктивност в големи екипи и в това няма съмнение. Много начинаещи програмисти се оплакват, че има много функции, които им липсват. Това желание за простота беше съзнателно решение на дизайнерите на езика и за да разберем напълно защо е необходимо, трябва да разберем мотивацията на разработчиците и какво се опитваха да постигнат в Go.

Така че защо беше направено толкова просто? Ето няколко цитата от Роб Пайк:

Ключовият момент тук е, че нашите програмисти не са изследователи. Те, като правило, са доста млади, идват при нас след обучение, може би са учили Java, или C/C++, или Python. Те не могат да разберат страхотен език, но в същото време искаме да създават добър софтуер. Ето защо езикът трябва да бъде лесен за разбиране и научаване.

Той трябва да е познат, грубо казано подобен на 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 има друг механизъм за създаване на генерични продукти - отражение. И ще са прави... но само в редки случаи.

Роб Пайк ни предупреждава:

Това е мощен инструмент, който трябва да се използва с повишено внимание. Трябва да се избягва, освен ако не е строго необходимо.

Уикипедия ни казва следното:

Отражението се отнася до процеса, по време на който една програма може да наблюдава и променя собствената си структура и поведение по време на изпълнение. Програмната парадигма, лежаща в основата на рефлексията, се нарича рефлективно програмиране. Това е вид метапрограмиране.

Както знаете обаче, за всичко трябва да платите. В този случай това е:

• трудности при писане на програми
• скорост на изпълнение на програмата

Следователно отражението трябва да се използва с повишено внимание, като оръжие с голям калибър. Безразсъдното използване на отражение води до нечетливи програми, постоянни грешки и ниска скорост. Точно нещо за един сноб програмист да може да се похвали с кода си пред други, по-прагматични и скромни колеги.

Културен багаж от Си? Не, от няколко езика!

Заедно със състоянието на наследниците остават и дългове.

Въпреки факта, че мнозина вярват, че езикът е изцяло базиран на наследството на C, това не е така. Езикът включва много аспекти на най-добрите езици за програмиране.

синтаксис

На първо място, синтаксисът на граматичните структури се основава на синтаксиса на езика C. Въпреки това, езикът DELPHI също имаше значително влияние. Така виждаме, че излишните скоби, които значително намаляват четливостта на програмата, са напълно премахнати. Езикът също така съдържа оператора “:=”, присъщ на езика DELPHI. Концепцията за пакети е заимствана от езици като ADA. Декларацията на неизползваните обекти е заимствана от езика PROLOG.

Семантика

Пакетите са базирани на семантиката на езика DELPHI. Всеки пакет капсулира данни и код и съдържа частни и публични обекти. Това ви позволява да намалите интерфейса на пакета до минимум.

Операцията за изпълнение чрез метода на делегиране е заимствана от езика DELPHI.

компилация

Не без причина има шега: Go е разработен, докато се компилира C програма. Една от силните страни на езика е неговата свръхбърза компилация. Идеята е заимствана от езика DELPHI. Всеки Go пакет отговаря на DELPHI модул. Тези пакети се прекомпилират само когато наистина е необходимо. Следователно след следващото редактиране не е необходимо да компилирате цялата програма, а по-скоро да компилирате отново само променените пакети и пакетите, които зависят от тези променени пакети (и дори тогава, само ако интерфейсите на пакетите са се променили).

Конструкции на високо ниво

Езикът съдържа много различни конструкции на високо ниво, които по никакъв начин не са свързани с езици на ниско ниво като C.

• линии
• Хеш таблици
• Резени
• Въвеждането на Duck е заимствано от езици като RUBY (който, за съжаление, мнозина не разбират или не използват пълния си потенциал).

Управление на паметта

Управлението на паметта като цяло заслужава отделна статия. Ако в езици като C++ контролът е изцяло оставен на разработчика, тогава в по-късните езици като DELPHI е използван модел за преброяване на препратки. С този подход цикличните препратки не бяха разрешени, тъй като бяха формирани осиротели клъстери, тогава Go има вградено откриване на такива клъстери (като C#). В допълнение, събирачът на боклук е по-ефективен от повечето известни в момента реализации и вече може да се използва за много задачи в реално време. Самият език разпознава ситуации, когато стойност за съхраняване на променлива може да бъде разпределена в стека. Това намалява натоварването на мениджъра на паметта и увеличава скоростта на програмата.

Паралелност и паралелност

Паралелизмът и конкурентоспособността на езика са извън похвала. Нито един език от ниско ниво не може дори отдалечено да се конкурира с Go. За да бъдем честни, заслужава да се отбележи, че моделът не е измислен от авторите на езика, а просто е заимстван от добрия стар език ADA. Езикът е в състояние да обработва милиони паралелни връзки, използвайки всички процесори, като същевременно има порядък по-малко сложни проблеми с блокирания и състезателни условия, които са типични за многонишков код.

Допълнителни предимства

Ако е печелившо, всички ще станат безкористни.

Езикът също така ни предоставя редица несъмнени предимства:

• Един изпълним файл след изграждането на проекта значително опростява внедряването на приложения.
• Статичното въвеждане и извеждането на типа могат значително да намалят броя на грешките във вашия код, дори без писане на тестове. Познавам някои програмисти, които изобщо не пишат тестове и качеството на кода им не страда значително.
• Много проста крос-компилация и отлична преносимост на стандартната библиотека, което значително опростява разработката на крос-платформени приложения.
• RE2 регулярните изрази са безопасни за нишки и имат предвидими времена за изпълнение.
• Мощна стандартна библиотека, която позволява на повечето проекти да работят без рамки на трети страни.
• Езикът е достатъчно мощен, за да се съсредоточи върху проблема, а не как да го реши, но достатъчно ниско ниво, за да може проблемът да бъде решен ефективно.
• Системата Go eco вече съдържа готови инструменти за всички случаи: тестове, документация, управление на пакети, мощни линтери, генериране на код, детектор за условия на състезание и др.
• Go версия 1.11 въведе вградено управление на семантични зависимости, изградено върху популярния VCS хостинг. Всички инструменти, съставляващи екосистемата Go, използват тези услуги, за да изтеглят, изграждат и инсталират код от тях с един замах. И това е страхотно. С пристигането на версия 1.11 проблемът с версиите на пакетите също беше напълно разрешен.
• Тъй като основната идея на езика е да намали магията, езикът стимулира разработчиците да обработват изрично грешките. И това е правилно, защото в противен случай той просто ще забрави напълно за обработката на грешки. Друго нещо е, че повечето разработчици умишлено игнорират обработката на грешки, предпочитайки вместо да ги обработват, просто да препратят грешката нагоре.
• Езикът не прилага класическата OOP методология, тъй като в чистата си форма няма виртуалност в Go. Това обаче не е проблем при използване на интерфейси. Липсата на ООП значително намалява бариерата за навлизане на начинаещи.

Простота в полза на общността

Лесно се усложнява, трудно се опростява.

Go е проектиран да бъде прост и успява в тази цел. Написано е за интелигентни програмисти, които разбират предимствата на работата в екип и са уморени от безкрайната променливост на езиците на корпоративно ниво. Имайки сравнително малък набор от синтактични структури в своя арсенал, той практически не подлежи на промени с течение на времето, така че разработчиците имат много време, освободено за развитие, а не за безкрайно изучаване на езикови иновации.

Компаниите получават и редица предимства: ниска входна бариера им позволява бързо да намерят специалист, а неизменността на езика им позволява да използват същия код дори след 10 години.

Заключение

Големият размер на мозъка никога не е направил слон носител на Нобелова награда.

За онези програмисти, чието лично его има предимство пред екипния дух, както и теоретиците, които обичат академичните предизвикателства и безкрайното „самоусъвършенстване“, езикът е наистина лош, тъй като е занаятчийски език с общо предназначение, който не ви позволява да получите естетическо удоволствие от резултата от работата си и да се покажеш професионалист пред колегите си (при условие, че измерваме интелигентността по тези критерии, а не по IQ). Както всичко в живота, това е въпрос на лични приоритети. Като всички иновации, които си заслужават вниманието, езикът вече е изминал дълъг път от всеобщото отричане до масовото приемане. Езикът е гениален в своята простота, а както знаете, всичко гениално е просто!

Източник: www.habr.com