Статијата е напишана како одговор на претходно објавена антиподен член.

Во текот на изминатите две и повеќе години користев Go за имплементирање на специјализиран сервер RADIUS со развиен систем за наплата. На патот, ги учам сложеноста на самиот јазик. Самите програми се многу едноставни и не се целта на овој напис, но самото искуство на користење на Go заслужува неколку зборови во негова одбрана. Go станува се повеќе мејнстрим јазик за сериозен, скалабилен код. Јазикот е создаден од Google, каде што активно се користи. Во крајна линија, искрено мислам дека дизајнот на јазикот Go е лош за НЕинтелигентните програмери.

Дизајниран за слаби програмери?

Слабите зборуваат за проблеми. Силните зборуваат за идеи и соништа...

Go е многу лесно за учење, толку лесно што можете да го прочитате кодот практично без никаков тренинг. Оваа карактеристика на јазикот се користи во многу светски компании кога кодот се чита заедно со несуштински специјалисти (менаџери, клиенти, итн.). Ова е многу погодно за методологии како што е Дизајн управуван развој.
Дури и почетниците програмери почнуваат да произведуваат прилично пристоен код по една или две недели. Книгата од која учев е „Оди програмирање“ (од Марк Самерфилд). Книгата е многу добра, допира многу нијанси на јазикот. По непотребно комплицираните јазици како Java, PHP, недостатокот на магија е освежувачки. Но, порано или подоцна, многу ограничени програмери имаат идеја да користат стари методи во ново поле. Дали е ова навистина потребно?

Роб Пајк (главниот идеолог на јазикот) го создаде јазикот Go како индустриски јазик кој е лесен за разбирање и ефективен за употреба. Јазикот е дизајниран за максимална продуктивност во големи тимови и нема сомнеж за тоа. Многу програмери почетници се жалат дека има многу функции што им недостасуваат. Оваа желба за едноставност беше свесна одлука на дизајнерите на јазикот, а за целосно да разбереме зошто е потребна, мора да ја разбереме мотивацијата на програмерите и што се обидуваа да постигнат во Go.

Па зошто беше направено толку едноставно? Еве неколку цитати од Роб Пајк:

Клучната точка овде е дека нашите програмери не се истражувачи. Тие се, по правило, доста млади, доаѓаат кај нас по студирањето, можеби студирале Java, или C/C++ или Python. Тие не можат да разберат одличен јазик, но во исто време сакаме да создадат добар софтвер. Затоа јазикот треба да биде лесен за разбирање и учење.

Тој треба да биде запознаен, грубо кажано слично на Ц. Програмерите кои работат во Google ја започнуваат својата кариера рано и главно се запознаени со процедуралните јазици, особено со семејството C. Барањето за брза продуктивност во новиот програмски јазик значи дека јазикот не треба да биде премногу радикален.

Мудри зборови, нели?

Артефакти на едноставноста

Едноставноста е неопходен услов за убавина. Лев Толстој.

Одржувањето едноставно е една од најважните цели во секој дизајн. Како што знаете, совршен проект не е проект каде што нема што да се додаде, туку оној од кој нема што да се отстрани. Многу луѓе веруваат дека за да се решат (или дури и да се изразат) сложени проблеми, потребна е сложена алатка. Сепак, тоа не е. Да го земеме на пример јазикот PERL. Јазичните идеолози веруваа дека програмерот треба да има најмалку три различни начини да реши еден проблем. Идеолозите на јазикот Go тргнаа по поинаков пат, тие одлучија дека еден начин, но навистина добар, е доволен за да се постигне целта. Овој пристап има сериозна основа: единствениот начин е полесно да се научи и потешко да се заборави.

Многу мигранти се жалат дека јазикот не содржи елегантни апстракции. Да, ова е точно, но ова е една од главните предности на јазикот. Јазикот содржи минимум магија - затоа не е потребно длабоко знаење за читање на програмата. Што се однесува до говорноста на кодот, тоа воопшто не е проблем. Добро напишаната програма Голанг чита вертикално, со мала или никаква структура. Дополнително, брзината на читање програма е барем ред на големина поголема од брзината на нејзиното пишување. Ако сметате дека целиот код има униформно форматирање (направено со помош на вградената команда 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)
}

Решението на истиот проблем во Д, иако изгледа нешто пократко, не е полесно за читање

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

И, иако нашиот код се покажа дека е нешто подолг од претходниот случај, тој стана генерализиран. Затоа, нема да ни биде тешко да ги спроведеме сите аритметички операции.

Многумина ќе речат дека програмата во Д изгледа значително пократка и ќе бидат во право.

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, ќе видите колку често се користат збунувачки интерфејси. Блиските другари веднаш ќе кажат дека сето тоа се должи на немањето генерики. Сепак, тоа не е секогаш случај. Да го земеме ДЕЛФИ како пример. И покрај присуството на истите овие генерики, тој содржи посебен тип VARIANT за операции со произволни типови на податоци. Јазикот Go го прави истото.

Од топ до врапчиња

А јакната мора да одговара на големината на лудилото. Станислав Лец.

Многу екстремни фанови може да тврдат дека Go има уште еден механизам за создавање генерики - рефлексија. И ќе бидат во право... но само во ретки случаи.

Роб Пајк не предупредува:

Ова е моќна алатка која треба да се користи со претпазливост. Треба да се избегнува освен ако не е строго неопходно.

Википедија ни го кажува следново:

Рефлексијата се однесува на процесот за време на кој програмата може да ја следи и модифицира сопствената структура и однесување за време на извршувањето. Програмската парадигма во основата на рефлексијата се нарекува рефлектирачко програмирање. Ова е еден вид метапрограмирање.

Сепак, како што знаете, треба да платите за сè. Во овој случај тоа е:

• тешкотии во пишувањето програми
• брзина на извршување на програмата

Затоа, рефлексијата мора да се користи со претпазливост, како оружје со голем калибар. Непромисленото користење на рефлексијата води до нечитливи програми, постојани грешки и мала брзина. Само она за сноб програмер да може да го покаже својот код пред други, попрагматични и поскромни колеги.

Културен багаж од Кси? Не, од голем број јазици!

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

И покрај фактот што многумина веруваат дека јазикот е целосно заснован на наследството Ц, тоа не е така. Јазикот вклучува многу аспекти од најдобрите програмски јазици.

синтакса

Пред сè, синтаксата на граматичките структури се заснова на синтаксата на јазикот C. Меѓутоа, значајно влијание имал и јазикот ДЕЛФИ. Така, гледаме дека непотребните загради, кои во голема мера ја намалуваат читливоста на програмата, се целосно отстранети. Јазикот исто така го содржи операторот „:=“ својствен за јазикот DELPHI. Концептот на пакети е позајмен од јазици како ADA. Декларацијата за неискористени ентитети е позајмена од јазикот PROLOG.

Семантика

Пакетите беа базирани на семантиката на јазикот DELPHI. Секој пакет содржи податоци и код и содржи приватни и јавни субјекти. Ова ви овозможува да го намалите интерфејсот на пакетот на минимум.

Операцијата за имплементација со методот на делегирање беше позајмена од јазикот DELPHI.

Компилација

Не е без причина што има шега: Go беше развиен додека се компајлираше програма C. Една од силните страни на јазикот е неговата ултра брза компилација. Идејата е позајмена од јазикот ДЕЛФИ. Секој Go пакет одговара на модул DELPHI. Овие пакети се прекомпајлираат само кога навистина е потребно. Затоа, по следното уредување, не треба да ја компајлирате целата програма, туку повторно да ги компајлирате само променетите пакети и пакети кои зависат од овие променети пакети (па дури и тогаш, само ако интерфејсите на пакетите се променети).

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

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

• Rици
• Хаш табели
• Парчиња
• Пишувањето со патка е позајмено од јазици како RUBY (кој, за жал, многумина не го разбираат или го користат до крај).

Управување со меморијата

Управувањето со меморијата генерално заслужува посебна статија. Ако на јазиците како C++, контролата е целосно препуштена на развивачот, тогаш во подоцнежните јазици како DELPHI, се користел модел за броење референци. Со овој пристап, цикличните референци не беа дозволени, бидејќи беа формирани сирачиња кластери, тогаш Go има вградено откривање на такви кластери (како C#). Покрај тоа, собирачот на ѓубре е поефикасен од повеќето моментално познати имплементации и веќе може да се користи за многу задачи во реално време. Самиот јазик препознава ситуации кога на оџакот може да се распредели вредност за складирање на променлива. Ова го намалува оптоварувањето на менаџерот за меморија и ја зголемува брзината на програмата.

Concurrency и Concurrency

Паралелизмот и конкурентноста на јазикот е надвор од пофалба. Ниту еден јазик на ниско ниво не може ни оддалеку да се натпреварува со Go. Да бидеме фер, вреди да се напомене дека моделот не бил измислен од авторите на јазикот, туку едноставно бил позајмен од стариот добар јазик АДА. Јазикот е способен да обработува милиони паралелни врски користејќи ги сите процесори, а притоа има понекомплексни проблеми со редослед на големина со ќор-сокак и услови за трка кои се типични за кодот со повеќе нишки.

Дополнителни придобивки

Ако е профитабилно, сите ќе станат несебични.

Јазикот исто така ни обезбедува голем број несомнени придобивки:

• Една извршна датотека по изградбата на проектот во голема мера го поедноставува распоредувањето на апликациите.
• Статичното пишување и заклучувањето на типот може значително да го намалат бројот на грешки во вашиот код, дури и без тестови за пишување. Познавам некои програмери кои воопшто не пишуваат тестови и квалитетот на нивниот код не страда значително.
• Многу едноставна вкрстена компилација и одлична преносливост на стандардната библиотека, што во голема мера го поедноставува развојот на апликации со повеќе платформи.
• Редовните изрази RE2 се безбедни за нишки и имаат предвидливи времиња на извршување.
• Моќна стандардна библиотека која им овозможува на повеќето проекти да работат без рамки од трети страни.
• Јазикот е доволно моќен за да се фокусира на проблемот наместо како да го реши, но сепак доволно ниско ниво за проблемот да може ефикасно да се реши.
• Еко системот Go веќе содржи развиени алатки надвор од кутијата за сите прилики: тестови, документација, управување со пакети, моќни линтери, генерирање кодови, детектор за услови за трка итн.
• Go верзијата 1.11 воведе вградено семантичко управување со зависност, изградено врз популарниот VCS хостинг. Сите алатки што го сочинуваат екосистемот Go ги користат овие услуги за преземање, создавање и инсталирање на код од нив со еден удар. И тоа е одлично. Со доаѓањето на верзијата 1.11, целосно беше решен и проблемот со верзијата на пакетите.
• Бидејќи основната идеја на јазикот е да се намали магијата, јазикот ги поттикнува програмерите експлицитно да ракуваат со грешки. И ова е точно, бидејќи во спротивно, едноставно целосно ќе заборави на справувањето со грешките. Друга работа е што повеќето програмери намерно го игнорираат справувањето со грешките, претпочитајќи наместо да ги обработуваат едноставно да ја препратат грешката нагоре.
• Јазикот не ја имплементира класичната OOP методологија, бидејќи во својата чиста форма нема виртуелност во Go. Сепак, ова не е проблем кога користите интерфејси. Отсуството на OOP значително ја намалува бариерата за влез за почетници.

Едноставност за корист на заедницата

Лесно е да се комплицира, тешко да се поедностави.

Go беше дизајниран да биде едноставен и успева во таа цел. Напишано е за паметни програмери кои ги разбираат придобивките од тимската работа и се уморни од бескрајната варијабилност на јазиците на ниво на Enterprise. Имајќи релативно мал сет на синтаксички структури во својот арсенал, тој практично не подлежи на промени со текот на времето, така што програмерите имаат многу време ослободено за развој, а не за бескрајно проучување јазични иновации.

Компаниите добиваат и бројни предности: ниската бариера за влез им овозможува брзо да најдат специјалист, а непроменливоста на јазикот им овозможува да го користат истиот код дури и по 10 години.

Заклучок

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

За оние програмери чие лично его има предност пред тимскиот дух, како и теоретичари кои сакаат академски предизвици и бескрајно „само-подобрување“, јазикот е навистина лош, бидејќи е занаетчиски јазик за општа намена што не дозволува естетско задоволство од резултатот на вашата работа и покажете се професионално пред колегите (под услов интелигенцијата да ја мериме по овие критериуми, а не според коефициентот на интелигенција). Како и сè во животот, тоа е прашање на лични приоритети. Како и сите вредни иновации, јазикот веќе измина долг пат од универзалното негирање до масовно прифаќање. Јазикот е генијален во својата едноставност, и, како што знаете, сè генијално е едноставно!

Извор: www.habr.com