Go на пальцах

я даже не буду тебе объяснять что разница ничтожна и ты сравниваешь язык с gc vs plain c, но ты видимо не поймешь.

Забавно, что несмотря даже на то, что качеством выдаваемого кода особо никто пока и не занимался, язык с GC и корутинами в коде сливает сишечке в производительности на сферических тестах всего в ~1.5 раза.

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

сразу видно специалиста.

не подскажешь, в каком месте содержится эта самая дополнительная информация, из которой можно понять, что указатель был обнулен, например, в функции X(), если мы грохнулись в функции Y() ?

Категорически не согласен, какая разница плодить if или try/catch?

Разница появляется когда обработать надо на много уровней выше. Тогда try/catch будет один, а с возвратом ошибок if с ранним выходом будет везде.

Забавно

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

сразу видно специалиста.

Без перехода на личности можешь?

не подскажешь, в каком месте содержится эта самая дополнительная информация

Нигде. Но пример можно взять менее дурацкий. Потому что у тебя мы не знаем где появилась проблема в момент её обнаружения. Правильный пример: у нас есть информация о проблема в момент возникновения. И мы можем или кинуть исключение со стек-трейсом, описанием и прочими подробностями. Или тащить все возможные ошибки через кучу уровней засирая сигнатуры функций.

Так и есть.

В Rust и RE2 перетащили.

Ну да

Разница в том, что первое нужно писать _всюду_, а второе — только там, _где необходимо_, хоть один раз на всю программу.

А в go есть что-то типа растового Result<T,E>?

Нигде. Но пример можно взять менее дурацкий.

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

исключения тут тебе никак не помогут - только старая добрая отладка. Что пришлось бы сделать и без try/catch.

Правильный пример: у нас есть информация о проблема в момент возникновения

откуда? Классический side-effect сделает тебе проблему, но ты не узнаешь, где, даже если программа хряпнется, ну или ты отловишь где-то исключение. А учитывая шо всё ООП построено на побочных эффектах - проблемы практически гарантированы.

И мы можем или кинуть исключение со стек-трейсом, описанием и прочими подробностями.

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

а если проверять и бросать - то отсутствие исключений в go вообще не проблема - можно тупо запаниковать, а наверху уже ловить. Если нам надо чтобы программа работала корректно, и выдавала информативные сообщения об ошибках - мы или вынуждены городить типы исключений, проверки, и бросания этих исключений, или заниматься проверкой результата и передавать ошибку наверх руками - если у нас нет ни исключений, ни panic/recover.

Излишней писанины можно избежать только в случае, если
1) на самом верху у тебя catch(Exception) // делаем вид, шо не упали
2) ты индус
3) ты работаешь в Microsoft, где, по-видимому, за сообщения об ошибках, написанные на человеческом языке - расстреливают сразу.

2) ты индус
3) ты работаешь в Microsoft,

наповал :-)))

поспрашивал поцанов на php.ru, никто про этот го не слышал, ниакого ажеоатжа

Да, ты сделал это явно в коде. О чем и говорится в сообщении, на которое ты отвечал.

какая разница плодить if или try/catch?

Если ты забьешь на if, то испортишь логику. Если ты забьешь на try/catch, исключение отправится выше. Кроме того, try/catch нужно существенно меньше.

Спасибо, исключений мы в Java накушались. После всех этих яв, рубей, питонов Go - как глоток свежего воздуха.

Вы просто говноеды, неспособные оценить и тем более создавать нормальные инженерные решения.

Go ущербен по самое не могу. Возврат в 70е.

Вы просто говноеды, неспособные оценить и тем более создавать нормальные инженерные решения. Go ущербен по самое не могу. Возврат в 70е.

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

исключения тут тебе никак не помогут - только старая добрая отладка. Что пришлось бы сделать и без try/catch.

Всё так. Вот только в этом моменте возврат ошибки совершенно ничего не меняет. Так смысл их противопоставлять?

Опять же, «NullPointerException» не везде есть.

откуда?

Из нашей логики. Скажем, парсишь ты файл и «что-то пошло не так». Можно просто сообщить, что «файл испорчен», можно указать на проблемную позицию в файле с подробностями - чего не хватает и что ожидалось.

Только это, опять же, можно делать как на «кодах возврата» (не на совсем примитивных, разумеется) так и на исключениях. У исключений очевидное достоинство - нам не надо размазывать «пробрасываем проблему» дальше по всем функциям. Так же не будет этот мусор в сигнатурах торчать. Естественно, есть и минусы и о них ты, похоже знаешь. Мой опыт говорит, что исключения могут быть полезны.

Собственно, даже в языках с «отказом от исключений» это проявляется. В расте, на мой взгляд, более удобные механизмы для возврата ошибки Option/Result и соответствующие функции/макросы. Но и там есть «паника». Которую изначально можно было только на границах потоков обрабатывать. Потом добавилась функция catch_panic, пока что нестабильная, посмотрим, что дальше будет. Заметно, что нужна в этих механизмах периодически есть. Вот только, что в Го, что в расте их сделали (насколько я могу судить) «намеренно неудобными», но пользоваться растовой/гошной паникой как исключениями можно. А для раста ещё и на макросах можно навелосипедить почти привычный вариант.

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

Именно этого не хочет делать KRoN73, гг

Нет, он хочет другого. А именно избежать вот этого мусора (псевдокод):

int f1() {
    if ... 
        return SOME_ERROR;
    ...
}

int f2() {
    result = f1();
    if IS_ERROR(result)
        return result;
    ...
    another_result = f1();
    if IS_ERROR(another_result)
        return another_result;
}

int f3() {
    result = f2();
    if IS_ERROR(result)
        return result;
    ...
}

...

А именно избежать вот этого мусора

а мне нра

Вот только в этом моменте возврат ошибки совершенно ничего не меняет. Так смысл их противопоставлять?

чтобы вернуть код ошибки - тебе _придется_ проверить данные.

Скажем, парсишь ты файл и «что-то пошло не так»

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

У исключений очевидное достоинство - нам не надо размазывать «пробрасываем проблему» дальше по всем функциям.

возвращаясь к упреку «в go нет исключений» - там ровно так же не надо «пробрасывать дальше по функциям» - этим «достоинством исключений» обладают паники.

Мой опыт говорит, что исключения могут быть полезны.

почти что угодно может быть полезно. Но, как правило исключения используют в качестве затычек, а потом кому-то это отлаживать, чтобы выяснить, почему «что-то пошло не так». Некоторые идут ещё дальше, и используют try/catch вместо if/then. Ну а чо, удобный способ выйти в нужное место вызывающей функции...

Нет, он хочет другого. А именно избежать вот этого мусора (псевдокод)

осталось только понять, кто его заставляет в go писать с этим мусором.

чтобы вернуть код ошибки - тебе _придется_ проверить данные.

А для исключения нет? Я ещё раз повторю NullPointerException (из твоего примера) есть не везде, то есть обычно исключения точно так же осознанно кидаются руками, а не сваливаются с неба.

задача тривиальная.

Ну-ну. Особенно если по файлу мы свой DOM строим и разбираем хотя бы что-то уровня ODF.

Спор-то в общем несколько о другом.

И о чём же? Изначально, я отвечал, что в исключениях будет ровно та же информация, что и в нормальном коде возврата - какую положишь, такая и будет. Ну и некоторые языки всё-таки стек вызовов сами в исключение упаковывают.

возвращаясь к упреку «в go нет исключений»

Покажи где я такое говорил. Но вообще забавно, конечно. То ты против исключений, то «в Го они тоже есть». Да, есть, но пользоваться ими как полноценными исключениями неудобно. Ну и почему-то многие говорят, что Го отказался от исключений, хотя это вопрос к ним, конечно.

почти что угодно может быть полезно.

Почти всё может быть использовано неправильно. И то не уверен, что слово «почти» тут нужно.

осталось только понять, кто его заставляет в go писать с этим мусором.

Отсутствие нормальных catch (с удобной поддержкой проверки принадлежности исключения к разным типам и т.д.)?

Но если ты ещё не заметил, то я не нападаю на Го. В расте точно так же, в свифте, вроде, ещё хуже. Мне просто этот «новомодный» подход не кажется удобным, только и всего.

полностью согласен. а еще это закаляет дисциплину.

Иссус Крестос семь дней и три ночи провисел на кресте ради наших грехов. неужели нам так трудно писать if/then ради Иссуса?

А для исключения нет?

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

Я ещё раз повторю NullPointerException

не надо мне повторять. Я тоже могу повторить, что нулевой указатель - самое явное проявление широкого класса ошибок. Про неверные данные я же писал уже? писал. Падения не будет, но результат работы будет неправильным. И опять же, повторюсь - исключение не дает нам информации - где и что испортилось. Если только это исключение не выбросили мы ручками в момент порчи, снабдив его внятной информацией

Ну-ну. Особенно если по файлу мы свой DOM строим и разбираем хотя бы что-то уровня ODF.

тривиальная. Если, конечно, не требуется восстанавливать поврежденный файл, но тут уже 99% ошибок будут в libastral.so

Изначально, я отвечал

изначально ты отвечал на мой ответ критике go за «отсутствие исключений» :)

Отсутствие нормальных catch (с удобной поддержкой проверки принадлежности исключения к разным типам и т.д.)?

ты хочешь сказать, что в go нельзя определить - что передали в панике?

Мне просто этот «новомодный» подход не кажется удобным, только и всего.

дело привычки

Про неверные данные я же писал уже? писал. Падения не будет, но результат работы будет неправильным.

Я правда не понимаю к чему ты клонишь. Скажем, расстрелять память можно везде (правда приложить придётся разные усилия) - тут не только данные испортить можно, а тот же стек. Как это вообще относится к исключениям, кодам возврата и обработке ошибок вообще?

Если только это исключение не выбросили мы ручками в момент порчи, снабдив его внятной информацией

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

тривиальная

Ты явно этим не занимался.

изначально ты отвечал на мой ответ критике go за «отсутствие исключений» :)

Ок, возможно, я влез немного не туда.

ты хочешь сказать, что в go нельзя определить - что передали в панике?

Нет, не хочу. Впрочем, я Го толком не знаю. Приведи, если не сложно, аналог такого:

catch(Exception1)
{ ... }
catch(Exception2)
{ ... }
catch(Exception3)
{ ... }
catch(BaseException)
{ ... }

дело привычки

Привыкнуть ко всему можно, но хочется-то больших удобств.

Скажем, расстрелять память можно везде

я не о расстреле памяти. О тупых алгоритмических/архитектурных ошибках, присущих всем достаточно сложным программам написанных на языках с побочными эффектами.

Как это вообще относится к исключениям, кодам возврата и обработке ошибок вообще?

я говорил о том, что исключение не содержит информации об ошибке, а только информацию о месте, где ошибка стала явной. Т.е. никаких преимуществ в общем-то у «стектрейса», о котором была речь нету (перед с-подходом, например)

Ты явно этим не занимался.

занимался. В общем-то нет ничего проще, чем парсить xml %)

Приведи, если не сложно, аналог такого:

как-то так:

if r := recover(); r != nil {
  switch r.(type) {
    case string:
    case runtime.Error:
    case int:
  }
}

Вообще, ни один из этих двух вариантов нельзя назвать хорошим. Хорошо, — это, например, Try в Scala.

Привыкнуть ко всему можно, но хочется-то больших удобств.

в сравнении с чем? go гораздо удобнее, чем python для создания не очень крупных веб-сервисов (и уж точно удобнее пхп и жабы)

можно, конечно на цепепе, но это уже будет сильно дороже

для нопейсания приложений под андроид go ещё очень долго будет менее удобным, чем java, не смотря на всякие go mobile

удобство языка - оно не сферическое в вакууме, а зависит от того - для чего язык используется.

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

Ну да, нет. Кроме возможности пробрасывать исключение через несколько уровней без лишнего синтаксического мусора.

В общем-то нет ничего проще, чем парсить xml %)

Особенно, если много файлов, которые ссылаются друг на друга.

как-то так:

Ок, спасибо. Кстати, как в этом примере обработать (проигнорировать) «любое исключение»? Или оно так и будет?

Ну и интересны ещё некоторые ситуации. Скажем, можно ли пробросить исключение дальше? Если мы укажем несколько типов исключения, а оно окажется другого типа - полетит дальше?

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

В любом случае, в расте с этим хуже. Там у исключения тоже «любой» тип (Any), только с ним работать не так удобно.

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

Нет ничего печальнее чем словить неспецифичный IndexError из глубин чужой библиотеки.

удобство языка - оно не сферическое в вакууме, а зависит от того - для чего язык используется.

Да в общем-то все перечисленные языки - общего назначения. Но мы ж именно про исключения говорим. Но похоже я был не прав и в го они более-менее есть.

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

Так-то да, но «уровень абстракции» - это ведь далеко не обязательно (скорее даже обязательно не) одна функция. То есть ифы писать придётся всё равно чаще.

Нет ничего печальнее чем словить неспецифичный IndexError из глубин чужой библиотеки.

Опять же, это слабо отличается от аналогичной ситуации с кодами возврата. Разве что они явно заставляют приводить ошибки к своим. Впрочем, никто, к сожалению, не запрещать возвращать какой-нибудь UNSPECIFIED_ERROR.

Error в го это кстати чуть больше чем код возврата. В себе он несёт как минимум человекочитаемое описание ошибки.

Кроме возможности пробрасывать исключение через несколько уровней без лишнего синтаксического мусора.

точно, ведь setjmp/longjmp ещё не изобрели %)

Особенно, если много файлов, которые ссылаются друг на друга.

тут всё зависит от того, как сильно мы должны поругаться перед тем как закончить обработку

Кстати, как в этом примере обработать (проигнорировать) «любое исключение»?

полетит дальше?

по умолчанию не полетит - запускать вверх надо руками

default: panic(r) - паникуем дальше, если тип мы не знаем (например)
если не паниковать - то получится что мы как бы обработали

В расте, к сожалению, ситуация хуже.

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

Error в го это кстати чуть больше чем код возврата.

В расте тоже. С сишными кодами возврата сравнивать не интересно. (:

В себе он несёт как минимум человекочитаемое описание ошибки.

Написать ерунду ведь никто не мешает? Да и это годится только если мы хотим сообщение «как есть» показать.

Да в общем-то все перечисленные языки - общего назначения.

это значит, что у них всего лишь нет специфической области применения. Не более того.

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

точно, ведь setjmp/longjmp ещё не изобрели %)

Скажи, что пошутил. Исключения отлично работают вместе с RAII. А setjmp/longjmp отлично подходит для стрельбы в ногу, особенно, если мы говорим не о С.

Ну и с исключениями код бросающий его ничего не должен знать о том кто, где и как будет их обрабатывать. С setjmp/longjmp «немного» не так.

default: panic(r) - паникуем дальше, если тип мы не знаем (например)

Правильно я понимаю, что default не обязателен и если мы не обрабатываем все варианты в switch, то Gо на это ничего не скажет?

Не очень удобно - добавился новый тип и мы об этом не узнаем, а молча проглотим проблему. В расте match должен покрывать все варианты, что весьма удобно (не в контексте исключений, а вообще) - если, скажем, добавилось новое значение в enum, то будет ошибка компиляции и надо будет его явно обработать или проигнорировать.

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

В каком смысле? Паника в языке УЖЕ есть. И в расте и в го. Тут или разработчики смогут между собой договориться и выработать общие подходы или или им никто не мешает нарушать даже официальные гайдлайны. Это (не)работает безотносительно языка.

Я о другом - Gо хоть и всячески рекомендует явную обработку ошибок, а не панику, но хотя бы не (сильно) связывает руки. В расте же нельзя просто поматчиться по Any. Можно, конечно, макрос написать, но хотелось бы, чтобы оно было из коробки.

Отрейзить фигню в исключении тоже труда не составляет.

Мне кажется, при максимально прямой архитектуре кода, когда IO код (основной источник ошибок/исключений) сидит в стеке вызовов как можно ниже, то и количество if-ов с проверками на ошибку не будет сильно выше количества try/catch'ей в ЯП с исключениями.

Скажи, что пошутил.

а я не шучу. Изобрели же. Просто утверждать, что не существует способа «бросить всё и сбежать» без исключений - не верно

особенно, если мы говорим не о С.

а о чем тут можно говорить? В остальных языках есть или исключения, или альтернативный способ «побега»

Правильно я понимаю, что default не обязателен и если мы не обрабатываем все варианты в switch, то Gо на это ничего не скажет?

не скажу точно сейчас, но конечно, type switch без default компилироваться не должен бы; впрочем, не вижу, почему бы такую проверку в компилятор не добавить (если её нет)

В каком смысле?

не, я сейчас про субъективщину «удобно». В том смысле, что «удобства» легко могут обернуться кривым кодом, который будет стрелять сначала в чужие ноги, а потом и в ноги своему создателю. И тут как-то оказывается, что «неудобные» ЯП снижают хромоногость девелоперов. Ну это мой опыт :)

В расте же нельзя просто поматчиться по Any.

ну видимо, для этого есть причины

Можно, конечно, макрос написать, но хотелось бы, чтобы оно было из коробки.

главное - не нарваться в итоге на причину, по которой в расте нельзя этого «из коробки»

Отрейзить фигню в исключении тоже труда не составляет.

Кто спорит?

В остальном, я считаю, что коряво использовать можно что угодно. Исключения бывают удобны. Банальный пример: out of memory. В большинстве случаев, обрабатывать не надо, но бывают исключения. Выносить это в сигнатуру функций? Тогда 90% функций будет с этой фигней. Вот тут исключения очень кстати.

В расте ещё решили, что целочисельное переполнения - это, как правило, ошибка. Проверять все операции тоже дорого, поэтому паника включена только в дебаге. Ну и есть отдельные функции для явного включения/отключения проверок. В этом случае, тоже удобнее через панику.

а о чем тут можно говорить? В остальных языках есть или исключения, или альтернативный способ «побега»

В swift, вроде, нет.

Ну и мне хотелось поговорить в общем о возврате ошибки/бросания исключения. Смысл предлагать нерабочий для большинства языков способ?

впрочем, не вижу, почему бы такую проверку в компилятор не добавить

Чтобы не ломать существующий код?.. Ну я хз как там в свифте, а тот же С++ это сильно «ограничивает».

ну видимо, для этого есть причины

Разве что нежелание того, чтобы панику как исключения использовали.

В swift, вроде, нет.

не поверил на слово. do, try, catch, guard, throw - всё есть

Ну и мне хотелось поговорить в общем о возврате ошибки/бросания исключения. Смысл предлагать нерабочий для большинства языков способ?

смысл был в том, чтобы показать, что вселенная существовала и до изобретения исключений.

Чтобы не ломать существующий код?

а с чего бы ему сломаться? автоматом вставить default: panic(r), если type switch по результату recover() - т.е. починить уже сломанный код, или вставить пустой default: если type switch по чему-то другому - и варнинг отобразить. Полагаю, в большинстве случаев будет достаточно

Разве что нежелание того, чтобы панику как исключения использовали.

это очень весомая причина. Потому как паника и исключения - всё-таки разные вещи

Нет и не будет - «дженерики нинужны».

go гораздо удобнее, чем python

/0 Я поверю в «быстрее». Я поверю в «параллельнее», ЕВПОЧЯ. Но вот про удобство - это или бред, или предельно жирный троллинг.

Вот тоже гениальная идея. Просто в шоке. Уверен, что если бы не бренд гугла, то у Go вообще бы ничего не вышло.

Убогий язык с убогими возможностями.

Я поверю в «быстрее».

«быстрее» - объективный критерий, «удобнее» - субъективный. Мне удобнее в больших проектах использовать языки, ограничивающие буйную фантазию.

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

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

Да практически любой язык. Тот же C++. В сети можно найти исследования на тему сравнения c++(tbb) и go, например.

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

Именованные возвращаемые значения?

Мне удобнее в больших проектах

go гораздо удобнее, чем python для создания не очень крупных веб-сервисов

Так о каких проектах все же речь?

Алсо, на мой взгляд, для удобства использования в вебе в языке должна быть либо чисто динамическая типизация(по возможности строгая, разумеется), либо крайне продвинутая статическая(Scala, Haskell) - это же веб, он полон JSON, SQL и прочего текста. В противном случае будет слишком много мусорного кода.

я так сходу и не назову конкурентов

Erlang же. В этом он рвет Go по всем статьям by design.

Убогий язык с убогими возможностями.

Вот да. По-моему, это такой PHP нашего времени - очередная большая ошибка.