"Они" говорили что дженерики не нужны. Потом "они" говорили что дженерики нужны? Кто "они"? Тот же Керниган или Пайк говорили? Основная задача разработки Go. Си-подобный код, максимально простой и понятный для "среднего" программиста с целью решения бизнес задач. Этим и объясняется недоООП и отсутствие других модных штук. И если средняя обезьяна не понимает ООП и дженерики... их не должно быть. Цель проста. Чтобы в коде разобрались и смогли поддерживать условные 100 миддлов. А не полтора сеньора, которых все ищут. Умные программисты безусловно нужны... но не нужны только Умные программисты, которых на рынке почти нет. Для работы программистом Go плох. Т.к со временем кардинально снизит уровень входа и зарплаты "умным". Задачи смогут решать не только они.

Go это public poll Тупой опрос – 30 👍👍👍👍👍👍👍 88% Тупой C – 3 👍 9% Тупой Python – 1 ▫️ 3% Тупой JavaScript ▫️ 0% 👥 34 people voted so far.

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

контрвариантность и ковариантность типов

контрвариантность и ковариантность типов

меня больше всего бесит обработка ошибок. 1. ошибке нужен стектрейс. сейчас я вынужден логировать ошибку на всех уровнях, на которых я ее обнаружил. даже если передаю ее выше без изменений. иначе поиски места, в котором ошибка действитель нопроизошла, становятся трудными 2. ошибке нужен тип. я хочу иметь возможность возвращать IO errors и input data errors так, чтобы их потом можно было отличить друг от друга. 3. ошибке нужен код. value который. я хочу иметь возможность сравнивать ошибки и выбирать обработку исходя из того, что именно вернулось. 4. Ошибке нужна возможность i18n сообщения

google for failure

меня больше всего бесит обработка ошибок. 1. ошибке нужен стектрейс. сейчас я вынужден логировать ошибку на всех уровнях, на которых я ее обнаружил. даже если передаю ее выше без изменений. иначе поиски места, в котором ошибка действитель нопроизошла, становятся трудными 2. ошибке нужен тип. я хочу иметь возможность возвращать IO errors и input data errors так, чтобы их потом можно было отличить друг от друга. 3. ошибке нужен код. value который. я хочу иметь возможность сравнивать ошибки и выбирать обработку исходя из того, что именно вернулось. 4. Ошибке нужна возможность i18n сообщения

* надо доклад сделать что ли

Лучше в отдельную либу и на гитхаб

вообще всё это лечится внесением тегированного enum (или тип сумм, или variant, называйте как хотите)

const iota?

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

А надо ли пихать что-то сложнее? И типы, кстати, никто не отменял

И проверка на совпадение

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

если у тебя что-то сложнее CRUD, то тебе нужны более развесистые ошибки

Например?

ты кишки наружу хочешь отдать

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

ну отдавай как строку, в чем проблема ?

Извините за глупый вопрос: а почему нельзя отдавать стракт, который удовлетворяет интерфейсу Error?

зачем обрабатывать?

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

- поля с зафейленной валидацией - контекстные ошибки (например ошибки, пришедшие от других сервисов или компонентов) - стектрейс - таймстемп - какие-то параметры для рековери - id запроса

и вот как вот это ты собираешься в автоматическом режиме обрабатывать ?

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

поле зафейлило валидацию - повторить 1000 раз пока не пройдет ?

вернуло тайстемп - проверить что мы в 21 веке , если нет запустить другую функцию ?

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

по мне все что не может быть решено на уровне вызывающем ошибки не должно выдавать детали реализации наружу

это не про детали реализации же)

для какого пользователя?)

вернуть признак наличия ошибки и строку для пользователя.

который в 2 часа ночи полезет в логи сонный смотреть что же там сломалось опять

рефакторить

как?