Go на пальцах

Объясните ньюфагу что в Go такого крутого, что в последнее время вокруг него такой ажиотаж

Приятный язык с быстрой компиляцией, лёгким рантаймом, сопрограммами и поддержкой DVCS-пакетов библиотек на уровне синтаксиса.

Правда, лично для меня есть серьёзный минус — отсутствие исключений. Возврат кода ошибки — это совсем не то.

Мне лень всё объяснять, пойди почитай faq.

ну там зато изкоробки поддерживается возврат нескольких значений из функции - это вполне себе компенсирует

Тебя еще не забанили?

ну там зато изкоробки поддерживается возврат нескольких значений из функции - это вполне себе компенсирует

Увы, нисколько :-/ Во-первых, синтаксис не очень удобный, мусор получается. Во-вторых, приходится ставить проверку на каждом уровне возврата. Количество паразитного кода возрастает многократно. Вместо того, чтобы сделать один try на высоком уровне и ловить исключение, где бы оно не вылетело, приходится добавлять десятки, даже сотни if'ов...

ну я в сорцах докера и swarm копался - там народ не напрягается

«Не напрягался» — это тупо игнорируют ошибки? Или то, что при просмотре сорцов не видно отсутствия напряжения от проверок на каждый чих? :)

...

Кстати, это и потенциально для надёжности чревато. Ставить проверки на каждый чих будет лениво и в ряде случаев проверки на ошибки будут опускать...

Ничего, честно говоря. И это круто.

Это опускание зато сразу видно. Наверное, можно даже хук на гит поставить.

Кстати, это и потенциально для надёжности чревато. Ставить проверки на каждый чих будет лениво и в ряде случаев проверки на ошибки будут опускать...

С эксепшонами точно такая же фигня

С эксепшонами точно такая же фигня

Нет. Там достаточно ловить «наверху», игнорируя всю низовую цепочку. На порядки меньше писанины.

Забанят, не бойся, всему свое время.

Количество паразитного кода возрастает многократно.

Ты ещё просто не пропитался духом Гожьим. Это вовсе не паразитный код. Это вполне реальные возможные состояния твоей программы. Или ты собрался тупо сказать юзеру: «То, что ты хотел, сделать не удалось, почему — ХЗ, сам разбирайся»?

Там достаточно ловить «наверху», игнорируя всю низовую цепочку.

руки отрубишь сам себе, при отладке

руки отрубишь сам себе, при отладке

Каким боком? Кто-то запретит мне увидеть трейс?

Хватит его кормить, модератор.

Кстати, это и потенциально для надёжности чревато. Ставить проверки на каждый чих будет лениво и в ряде случаев проверки на ошибки будут опускать...

Для этого есть errcheck.

Каким боком? Кто-то запретит мне увидеть трейс?

1. а с чего это ты его увидишь, если ты наверху все ловишь? Если ловишь - то как-то обрабатываешь, правильно?

2. с каких пор трейс показывает что-то кроме цепочки вызовов?

3. исключения должны быть отдельно, ошибки - отдельно.

касательно go - тебе надо проверять результат обращения к чужим функциям, паниковать если чего (это если ленишься вверх передавать код ошибки), и наверху панику ловить.

что в Go такого крутого

это такой erlang для неосиливших

Нет. Там достаточно ловить «наверху», игнорируя всю низовую цепочку. На порядки меньше писанины.

Тем не менее, там тоже >ставить проверки на каждый чих будет лениво и в ряде случаев проверки на ошибки будут опускать...: либо будет лень декларировать везде возвращаемые эксепшоны (java), либо это будет слишком неявным, стремным и неочевидным (python)

Тема холиворная.

Лично меня больше достаёт даже не сам факт проверок, которых могло бы не быть, а постоянный дубляж числа аргументом при возврате ошибки. На каждой проверке — типа такого:

    if len(parts) == 0 {
        return nil, nil, ErrNoComponents
    }

    h, err := mh.FromB58String(parts[0])
    if err != nil {
        log.Debug("given path element is not a base58 string.\n")
        return nil, nil, err
    }

Поменял число аргументов функции — добро пожаловать на переписывание всех возвратов... Это «эргономика программирования» уровня 1980-х годов.

И при этом трейс ошибок теряется. В итоге получаешь наверху ошибку и часто, чтобы понять откуда она, нужно изучать потроха в глубину.

Роб Пайк далеко, но мужик-то он нашенский. Я его видел, когда в Google работал, даже разговаривал с ним. В кепке, ростом невелик, с лукавым прищуром. Он такой... Даже и не расскажешь. Он прост, как правда.

Таков и Go.

И при этом трейс ошибок теряется.

https://github.com/ansel1/merry

На порядки меньше писанины.

Чтобы знать, что случилось, и что теперь делать, надо пробросить некислую часть стейта в исключении, а это сводит на нет преимущества (просто переносит часть кода обработки вовнутрь) и усложняет или запрещает рестарты. Исключения плохи тем, что их нельзя остановить и обработать в момент бросания, а также тем, что в генерик-кетче вообще нельзя уверенно что-то сделать, кроме лог/аборта, т.к. не все ресурсы являются самооткатными как память и лок-файлы. Любой успешный рид-врайт или запись в шаред-буфер/очередь перед исключением и вот мы в заднице.

Более лучшим подходом имхо является делегация избранных ошибок в *конкретных* местах, а по остальным нужно просто падать. Пойманный из сложного фреймворка голый EFileAccessDenied вообще ни о чем не говорит, а создавать класс на каждый чих — читай первый абзац.

В идеале нужно пробрасывать вверх continuation и cancellation хандлеры с описанием проблемы (ну или вниз в функциональном стиле), но помощи от языка или ide, чтобы было меньше писанины и асинхронки я нигде не видел.

Кстати cocoa юзает именно такой подход — его стандартный NSError выкидывается вверх с опциональным рекавери-функтором (то есть контекст при желании не разрушается), а исключения кидаются только на программные ошибки вроде выхода за пределы или вызов неверного селектора. Обрабатывать их можно только с целью скорейшего выхода.

Поменял число аргументов функции — добро пожаловать на переписывание всех возвратов…

Имхо, если возвращаемых значений больше двух (ну максимум трех) - пора их заворачивать в структуру.

И при этом трейс ошибок теряется. В итоге получаешь наверху ошибку и часто, чтобы понять откуда она, нужно изучать потроха в глубину.

Есть такая либа: https://github.com/juju/errgo/. При её использовании, соответственно делать так например:

return errors.Mask(err)

return err

Это «эргономика программирования» уровня 1980-х годов.

Именно так. Пилят уберинтерфейсы для юзеров с блекджеком и прозрачностью, а для программистов один раз блокнот написали и все, ипитесь как хочете. Все текст же.

Поменял число аргументов функции — добро пожаловать на переписывание всех возвратов...

В говно-языках всегда так. А в продуманных языках можно подписывыться на то количество возвращаемых аргументов, которое необходимо, остальные можно просто проигнорировать:

CL-USER> (get-decoded-time)
19
28
10
16
7
2015
3
NIL
-7
CL-USER> (multiple-value-bind (ss mm hh)
             (get-decoded-time)
           (format t "~2,'0D:~2,'0D:~2,'0D" hh mm ss))
10:30:18
NIL

Тебя еще не забанили?

Обращение к модераторам

В ваших продуманных языках зато скобки замучаешься учитывать. Лучше уж аргументы посчитать...

Лично для меня решающим аргументом стало что его может любой нормальный программист за неделю освоить. Т.е. как компромис между тем, что я хочу от языка, и тем, что на нём кодит сосед.

Лучше уж аргументы посчитать...

А потом также: «постоянный дубляж числа аргументом при возврате ошибки», «переписывание всех возвратов», «трейс ошибок теряется» и «нужно изучать потроха в глубину».

csp +" tooling of old_plain_c"

эээ «не надо писать фортран-style в непредназначеном месте»

можно предположить что создатели языка :

отказались от подхода: «брось ошибку вызвавшему из далёка» а считают что ошибка должна быть обработана(преобразована) непосредственным вызывающим либо(как вариант таковой обработки) им же подавлена .

тогда не будет гирляндирования условий по мере удаления от источника ошибки.

Объясните ньюфагу что в Go такого крутого

Яркий пример того, как можно взять кусок овна, прилепить к нему конкурентность и компиляцию в нативный код и втюхать массам с этикеткой Google, и все будут пищать.

Скажу за себя. Мне понравилось (когда я его первый раз пощупал в версии 0.7 вроде) то, что из коробки была поддержка vim-а с автодополнением, отличные отладчик и профилировщик, очень простая и понятная возможность подключать библиотеки С. А еще то, что не нужно писать мейкфайлы, и что разделение платформозависимого кода делается через имена файлов. Это в первую очередь.

А уже во-вторую - go routines и каналы, интерфейсы и прочие мелочи.

С другой стороны, код с ООП на утиной типизации мне сложно читать и понимать, и сам код, как мне кажется, выглядит некрасиво.

Компилируемость, сильная типизация, лаконичный и гибкий синтаксис, библиотеки для многих нужд «из коробки» (в частности для Веб).

это такой erlang который не тормозит

fixed for you

Увы, нисколько :-/ Во-первых, синтаксис не очень удобный, мусор получается. Во-вторых, приходится ставить проверку на каждом уровне возврата.

Категорически не согласен, какая разница плодить if или try/catch? второй даже более монструозное, а первое сильно дешевле

первое сильно дешевле

Я бы так категорично не заявлял.

Go тормозит.

Разница в том, что try catch позволяет обрабатывать ошибки там, где это нужно делать. И не позволяет неявно «замолчать» или тупо пропустить ошибки дальше. Это можно сделать, но только явно в коде.

no

Erlang - нишевый язык. И в этой самой нише Go до него как раком до Китая.

настолько нишевый, что скоро не будет нужен вообще, продукты на го появляются как грибы после дождя

настолько нишевый, что скоро не будет нужен вообще, продукты на го появляются как грибы после дождя

Go уже умеет все то же что Erlang/OTP?

yes

yes

Ну да:

f, _ := os.Open("/etc/passwd")
...

try:
  f = open("/etc/passwd")
except:
  pass
...

2. с каких пор трейс показывает что-то кроме цепочки вызовов?

У исключений обычно есть тип и может содержаться дополнительная информация.

https://github.com/ansel1/merry

Это хорошо, кстати, в расте подобное тоже навелосипедили. Вот только не будет все библиотеки это использовать. Если бы оно из коробки было...