интерфейсы в GO

на нем пишут от консольниых утилит и до высоконагруженных сетевых сервисов

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

Ты же понимаешь, что даже в сишке разработчики извращаются с return -1 и всякой нечистью с глобальными флагами, лонгджампами и прочей мутотенью вместо того чтоб договориться о том, что результатом return всегда должен быть struct у которого есть поле bool isFine или как там они договорятся, дальше data, где собственно твоё значение и errorMessage куда можно внести текст с описанием ошибки. Так почти никто никогда не пишет. Надо ли объяснять почему это хуже, чем try catch с механизмом исключений? Хотя если сахаром присыпать и язык изначально с таким подходом делать, то может и можно что-то приличное слепить. Только надо у каждого типа делать метод isFine и getError. Или даже достаточно getError и возвращать текстом пустую строку, если всё хорошо и что-то непустое в противном случае.

В Go, конечно, тоже придётся попрыгать. И return, и throw – похожие механизмы прерывания потока выполнения. Но в случае с Go тебе достаточно подняться на один уровень вверх и ты уже стоишь на строке, которая пробрасывает или обрабатывает ошибку. “return fmt.Errorf” — это тоже полезная информация, сразу сообщающая «не здесь». В Java недостаточно подняться на один уровень вверх, придётся ещё проверить список throws, окружающий try {} catch блок, который дополнительно зависит от иерархии типов. Нет локальности проброса как лексического понятия, то есть возможности понять поведение кода, глядя только на текущую функцию и её непосредственное окружение, а имеющаяся лексическая информация вроде throws неполна.

Да всё просто. Поднимаешься, пока не найдёшь catch. Я просто не понимаю, зачем это всё? Я 20 лет пишу на Java и никуда не поднимаюсь никогда. Ошибка в любом случае будет где-то обработана. Про это просто не надо думать. Ты думаешь про business value. Про счастливый путь выполнения. И сам становишься счастливей. Потом уже задеплоишь, увидишь в логах, что какой-то конкретный кейс спамит стектрейсами и решишь, что вот именно тут можно сделать более конкретную обработку, возвращая не 500, а что-нибудь более конкретное, например. Но это одна ошибка из миллиона возможных, а оставшийся миллион всё так же обрабатывается автоматически и без приложенных усилий.

Исключения изначально были созданы для обработки исключительных ситуаций. Именно поэтому им позволено так легко ломать поток выполнения. Но не все ошибки должны быть исключительными. Нет ничего исключительного, достойного сказать «не моя проблема», если, например, файл вдруг не открылся. Java попыталась адаптировать исключения, сделав их более контролируемыми, но тем самым смешала два принципиально разных понятия в одну неразличимую кучу. (Unchecked исключения делают проблему ещё острее.)

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

Например, ловим мы IOException. Его может выбросить бд, устанавливающая соединение через соккет, или запись в логи. При записи в логи не нужно прерывать работу метода. Это не редкость. И в чём преимущество централизации?

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

Да, Java даёт определённые гарантии, но при этом поощряет перекладывание исключения в throws. Учитывая то, кто каллером может быть потенциально кто угодно, всегда есть надежда, что где-то в глубине есть могучий Атлант try-catch, который точно знает что делать с твоим исключением.

Да нет никакого throws, я уже написал, что checked исключения никем не используются. IOException надо просто сразу же оборачивать в UncheckedIOException из стандартной же библиотеки и дальше забывать про него.

Никто не запрещает захватывать стек-трейс в Go. Никто, вроде, не считает это неправильным.

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

Для меня любой стектрейс это работа на 2 минуты. Ты просто щёлкаешь по именам файлов, строкам в IDE и перед тобой кристально ясная картина произошедшего. Если говорить про идеальный мир, я бы вообще хотел, чтобы в стектрейс дампились значения всех локальные переменных и параметров, если бы я делал свой ЯП, я бы так и сделал. Но в принципе и так сойдёт. А когда есть кристально ясная картина произошедшего, то работа над ошибкой проста и быстра.

А в Go мы видим bla: foo: bar в логе. И почесав в затылке начинаем писать grep -R 'bla' ., видим 20 вхождений, потом грепаем по foo и начинаем строить граф вызовов между всем этим безобразием, пытаясь предположить, хотя бы где именно эта ошибка возникла, на какой строке, про причину тут пока даже разговора не идёт. Это как махать каменным топором после бензопилы.

Всё преимущество Go в шикарной реализации. Удобный набор инструментов для разработки. Шикарный компилятор, наверное самый быстрый в индустрии. Скомпилированный код работает шустро. GC очень хороший. Зелёные потоки, идея на мой взгляд спорная, но тут у меня твёрдого мнения нет, и в Go они сделаны на отлично. В общем как язык - так себе. А как реализация - да, всё прям супер. И это в общем-то побеждает в итоге. Java как язык может и лучше, но там VM будет стартовать полсекунды, а в Go программа за это время успеет отработать десять раз, и пользователю просто будет приятней пользоваться такой программой.

Да ты и не сможешь

Универсальных языков нет в принципе. Каждый ЯП - это DSL.

Для меня выглядит довольно дико писать код, не думая об ошибках. Даже если тебе на 99% пофиг, 1% может быть важным, закрывать на него глаза до последнего момента ненадёжно. Таймауты, доступ к ресурсам, неверный ввод — это рутина, а не чья-то чужая забота. И когда я попадаю в незнакомый код, то локальность проброса позволяет легче понять что происходит. Я никогда не чувствовал потребности видеть только счастливый сценарий чужого кода.

закат солнца вручную

errors.Wrapf — не закат солнца вручную. Но я могу понять, если тебе приходится работать с проектом, где этого нет или вместо точной строки написано “failure: failure: failure.” Я за 8 лет опыта на Go с таким сталкивался редко.

Клоун ты :) тяжело, наверное, тебе живется с таким букетом комплексов

Для меня выглядит довольно дико писать код, не думая об ошибках.

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

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

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

errors.Wrapf

Что такое errors? Это This repository was archived?

Насколько я знаю, стандартный способ в Go нынче это fmt.Errorf в который вообще-то могли бы добавить информацию о стектрейсе, пускай даже включаемую через какой-нибудь ENV или ещё как-нибудь.

про бесполезность интерфейсов

в который вообще-то могли бы добавить информацию о стектрейсе

error это же интерфейс, в нем нет никакой информации

Дату выпуска посмотри :)

fmt.Errorf в который вообще-то могли бы добавить информацию о стектрейсе

Вот такой велик давеча нашел. Сам не пробовал еще.

Но там

To achieve the performance above on supported systems, errtrace makes use of unsafe operations

ко-ко-ко итокдалие )))

Сделать свой класс ошибки с фреймом стектрейса я, наверное, и сам смогу, не рокет саенс, тут дело не в этом, а в том, что хочется писать идиоматичный код, а идиоматичный код это fmt.Errorf.

жму руку