Холивар: го-шный if err != nil против rust-овского ? — кто кого

[Farkle]

Опять читаю тред где растовики ноют что в Go на каждой второй строчке if err != nil. Народ, это фича, а не баг. Я открываю функцию и сразу вижу где она может упасть, без магии. За 4 года на Go ни разу не пожалел.

[rabbit8]

Видеть где может упасть это хорошо. Плохо когда ты забыл проверить err и компилятор тебе ничего не сказал. В Rust Result<T,E> ты физически не достанешь значение не разобравшись с ошибкой. Это не вкусовщина, это разные гарантии.

[kernel_veteran]

errcheck в линтере ловит это на ура, у нас в CI стоит, не пройдёт MR с проигнориным err.

[wasmsre]

errcheck ловит когда ты вообще проигнорил. Не ловит когда ты проверил не ту ошибку или вернул err не обернув. Я лично три раза за прошлый год дебажил прод где err проглатывался внутри defer. Линтер молчал.

[jwmaiden]

сижу со стороны Python и потягиваю чаёк, у вас тут exceptions головного мозга наоборот

[vlad1]

anton_py у тебя try/except который ловит всё подряд и роняет прод когда ты поймал не то. Не начинай.

[cordoba]

Справедливости ради, в Go 1.13+ есть errors.Is/As и %w для оборачивания. Кто пишет на errors.New и потом strings.Contains по тексту ошибки — тех на мороз. Большинство жалоб на Go error handling это жалобы на код 2016 года.

[SparkMain]

А я помню как Go-команда зарубила try() предложение в 2019 и народ бомбил полгода. До сих пор нет нормального синтаксиса, и не будет. Россер сказал verbose это by design.

[matguyvr]

У меня сервис на Rust, и честно — ? оператор это кайф пока ошибки одного типа. Как только в одной функции три разных Error, начинается ад с From impl или anyhow/thiserror. Тоже не бесплатно.

[Version]

thiserror для библиотек, anyhow для приложений, это устоявшийся паттерн. 15 минут разобраться и забыть. Не сравнить с ручным оборачиванием каждой строки в Go.