А я иначе эту статью вижу. Она про конфликт между понятиями «хороший»/«плохой» между теоретиками и практиками. Когда ты один, ради интереса учишь языки, пытаешься на них что-нибудь «выражать» на синтетических или не очень примерах — у тебя одни представления о том, что будет хорошо, а что нет. Когда же ты попадаешь в «реальный мир» — работаешь с массой других людей, разных компаний, большим количеством чужого кода — начинаешь совсем иначе относиться. И в этой статье как раз хорошо проиллюстрирован вот этот сдвиг (хоть и не окончательный) приоритетов с «теоретика» на «практика» — автор только коммуницируя с другими начал понимать, что возможно, то что ему кажется «объективно хорошим» — не совсем то, что нужно в реальном мире.
Я уже писал такую статью тут на Хабре, но, скорее всего, я сам не знаю всех причин. Понимаете, как выходит — я больше практик, чем теоретик. Go достаточно сильно повлиял на моё отношение к ошибкам, тут и язык, и культура, и статьи на эту тему, и код, который я вижу у других — все вместе. То, что вижу на практике, подтверждается словами массы других людей, которые говорят тоже самое.
Поэтому если вы только ищете «формальных математических доказательств», почему так происходит — и все мои аргументы отметаете, потому что «там тоже можно проигнорировать» — боюсь, я вам не помогу.
Может быть, если бы вы сами стали практиком, и пописали немного на Go (не одну недельку, всмысле), вы бы нашли более правильное и емкое объяснение, почему Go производит такой эффект.
Но мне, все же, более важно, что это так на практике, даже если я это не могу донести «теорией» :)
Спасибо за урок воспитания и аргументацию в стиле «спорит с очевидными истинами», отвечу вам просто. Когда два человека сравнивают А и Б, и один из них не пробовал Б, но доказывает, что Б хуже, потому что он привык к А — он заведомо неправ. Вот и мне хотелось бы от некоторых яростных комментаторов тут, чтобы вы строили свои мнения объективно, а не прикрывались отсутствием знаний и «очевидными истинами».
Смотрите, статья о том, что в Go вы не относитесь к ошибкам, как к чему-то лишнему и код обработки ошибок не воспринимаете, как что-то, что «захламляет остальной код». И этот ведёт к тому, что у вас не стоит вопрос «как не игнорировать ошибки».
Поэтому ваши комментарии в стиле «в примере на counter просто забить» — это именно то, что говорит, что вы не поняли посыл статьи, и продолжаете мысли своим «докажите, что Go мне не даст забыть про ошибку». Что, впрочем, лучше, чем «не хочу захламлять код проверками ошибки» :)
Во-первых, есть принципиальная разница — в Go возвращается не struct, а интерфейс — этого вы в C не можете сделать по определению. Да, в некоторых С-библиотеках используются error-типы, но сценарий их применения достаточно ограничен.
Во-вторых, детали имеют значение — там где в С было просто забить на код возврата, в Go, чаще всего, нужно сознательно забить, еще и написать _ и проигнорировать ругательства линтера.
Давайте заканчивать эту «дискуссию». Я вам пишу как мне звучат ваши слова, а вы мне «нет, вам они звучат не так».
Ну и суть статьи вы так и уловили — хотя в этом, конечно же, и моя вина, как автора статьи.
В зависимости от задачи. Вы, кажется, так и не поняли, о чем речь.
Мне ваш вопрос звучит так:
«И какие вы действия делаете, когда получаете корень квадратный из функции, которая считает корень квадратный? Кстати, разбираете ли сам факт корня, или для каждого кейса делаете ветку?»
Глупо звучит, согласитесь)
интерфейс, позволяющий реализовывать свои статические типы, которые будут передаваться в качестве ошибки
Как человек, который долго писал на С, и достаточно долго пишет на Go, вижу, что это big deal, и эти различия кардинально меняют комфорт и ход работы. А вы на чем пишете, что не можете/не хотите увидеть различий и их последствий на практике?
Ну, мы тут уходим в дискуссию «исключения vs возвращаемые значения», а она на много страниц будет :)
Но первый код экономит строчки, но прячет полностью логику того, где и что происходит (и происходит ли) во время ошибки в любой из тех функций. Это здорово поначалу, но по мере того, как над кодом работают несколько поколений программистов, и код рефакторится несколько раз — обработка ошибок оказывается слабым местом. Второй код более многословный, но дает вам(и другим программистам, которые придут после вас) сразу всю картинку целиком, дает гибкость в реализации различного поведения в каждом случае, и, что самое главное, делает ошибку — таким же полноправным членом функции, о котором нужно заботится и понимать, зачем она тут и что с ней будет.
Ну и это, кажется вы прекратили со мной говорить во всех будущих темах. Что же случилось?
Вправду хотите знать? Я не вижу смысла общаться с человеком, который так возносит себя над всеми остальными, включая пионеров computer science, унижает их и новые для себя технологии, лишь из-за того, что привык работать с другими технологиями. Никогда не понимал таких людей, и таких яростных я ещё встречал. Удачи в борьбе с Го и несогласными с Вашим Единственным Истинным Мнением.
Тот же, да не тот же. Повторюсь, сказать «А похож на Б, следовательно имеет те же проблемы» — грубая логическая ошибка.
Можно себя долго обманывать и искать в Go новизну, но как уже множество раз говорилось авторами языка — в нем нет ничего нового.
Я так понимаю, из моей фразы в статье «подход Go тут является и зрелым и свежим одновременно» вы выбрали слово «свежим», проигнорировали слово «зрелым» и пытаетесь обвинить меня в предвзятости. Непонятно зачем только вы так тратите своё время.
Оу, спасибо. Это при копировании в/с медиума поменялось.
Для возможности запустить код — лучше переходите в песочницу, там под каждым сниппетом ссылки — там полная версия кода.
Отлично. Вы прекрасно демонстрируете то, с чем борется Go — с отношением к ошибкам, как к чему-то лишнему, как к недоразумению. И подход «ошибки это значения» заставляет вас так не относиться. Вы лучше всего продемонстрировали суть статьи :)
Хотя я уверен что никто из присутствующих ни разу не пытался что-то сделать с ошибками функции write.
*Всегда* проверяю ошибку после Write. Большинство знакомых мне Go-программистов — тоже. Непонятно, откуда у вас такая уверенность, особенно когда целые статьи пишут, с объяснением о том, почему в Go «не проверять» ошибки без повода — это редкость и моветон.
Давайте говорить в контексте статьи. Возьмите ваше утверждение, и замените «ошибку» на «переменную». Почему вам не хочется возмущаться, что в языке нет механизма проигнорировать возвращаемую переменную? Поймите, в Go:
state := foo.State()
и
err := foo.CheckUser()
это одинаковые вещи, вы работаете с ними теми же средствами языка.
Ну и я вам, как практик говорю — в Go, в большинстве своем, не игнорируют ошибки, поэтому любые ваши доводы о том, что «раз ошибку можно проигнорировать, значит в Go все игнорируют ошибки» обречены на провал. Это просто расходится с реальностью.
Да, но согласитесь увеличение сложности, связности и глубины абстракций — это вопрос архитектуры и дизайна. На Go не пишут гигантские энтерпрайз-монолит системы, но пишут гигантские распределенные системы. Это не дань моде, это реальная потребность современных систем.
Возможно, Go далеко не лучший язык для написания раздутого гигантского монолита, да. Но он отличен для создания распределенных систем, наверняка использующих SOA дизайн, кодовые базы которых при этом остаются достаточно гибкими для роста, рефакторинга и работы больших групп программистов.
Это реально так или просто излишнее утрирование?
Да и haskell vs go совсем не то же самое, что asm vs js. Так что такой себе сарказм )
Поэтому если вы только ищете «формальных математических доказательств», почему так происходит — и все мои аргументы отметаете, потому что «там тоже можно проигнорировать» — боюсь, я вам не помогу.
Может быть, если бы вы сами стали практиком, и пописали немного на Go (не одну недельку, всмысле), вы бы нашли более правильное и емкое объяснение, почему Go производит такой эффект.
Но мне, все же, более важно, что это так на практике, даже если я это не могу донести «теорией» :)
Поэтому ваши комментарии в стиле «в примере на counter просто забить» — это именно то, что говорит, что вы не поняли посыл статьи, и продолжаете мысли своим «докажите, что Go мне не даст забыть про ошибку». Что, впрочем, лучше, чем «не хочу захламлять код проверками ошибки» :)
Хоть лбом об стенку бейся ))
Во-вторых, детали имеют значение — там где в С было просто забить на код возврата, в Go, чаще всего, нужно сознательно забить, еще и написать _ и проигнорировать ругательства линтера.
Давайте заканчивать эту «дискуссию». Я вам пишу как мне звучат ваши слова, а вы мне «нет, вам они звучат не так».
Ну и суть статьи вы так и уловили — хотя в этом, конечно же, и моя вина, как автора статьи.
Мне ваш вопрос звучит так:
«И какие вы действия делаете, когда получаете корень квадратный из функции, которая считает корень квадратный? Кстати, разбираете ли сам факт корня, или для каждого кейса делаете ветку?»
Глупо звучит, согласитесь)
Как человек, который долго писал на С, и достаточно долго пишет на Go, вижу, что это big deal, и эти различия кардинально меняют комфорт и ход работы. А вы на чем пишете, что не можете/не хотите увидеть различий и их последствий на практике?
Но первый код экономит строчки, но прячет полностью логику того, где и что происходит (и происходит ли) во время ошибки в любой из тех функций. Это здорово поначалу, но по мере того, как над кодом работают несколько поколений программистов, и код рефакторится несколько раз — обработка ошибок оказывается слабым местом. Второй код более многословный, но дает вам(и другим программистам, которые придут после вас) сразу всю картинку целиком, дает гибкость в реализации различного поведения в каждом случае, и, что самое главное, делает ошибку — таким же полноправным членом функции, о котором нужно заботится и понимать, зачем она тут и что с ней будет.
Вправду хотите знать? Я не вижу смысла общаться с человеком, который так возносит себя над всеми остальными, включая пионеров computer science, унижает их и новые для себя технологии, лишь из-за того, что привык работать с другими технологиями. Никогда не понимал таких людей, и таких яростных я ещё встречал. Удачи в борьбе с Го и несогласными с Вашим Единственным Истинным Мнением.
Тот же, да не тот же. Повторюсь, сказать «А похож на Б, следовательно имеет те же проблемы» — грубая логическая ошибка.
Я так понимаю, из моей фразы в статье «подход Go тут является и зрелым и свежим одновременно» вы выбрали слово «свежим», проигнорировали слово «зрелым» и пытаетесь обвинить меня в предвзятости. Непонятно зачем только вы так тратите своё время.
Для возможности запустить код — лучше переходите в песочницу, там под каждым сниппетом ссылки — там полная версия кода.
Отлично. Вы прекрасно демонстрируете то, с чем борется Go — с отношением к ошибкам, как к чему-то лишнему, как к недоразумению. И подход «ошибки это значения» заставляет вас так не относиться. Вы лучше всего продемонстрировали суть статьи :)
*Всегда* проверяю ошибку после Write. Большинство знакомых мне Go-программистов — тоже. Непонятно, откуда у вас такая уверенность, особенно когда целые статьи пишут, с объяснением о том, почему в Go «не проверять» ошибки без повода — это редкость и моветон.
и
это одинаковые вещи, вы работаете с ними теми же средствами языка.
Ну и я вам, как практик говорю — в Go, в большинстве своем, не игнорируют ошибки, поэтому любые ваши доводы о том, что «раз ошибку можно проигнорировать, значит в Go все игнорируют ошибки» обречены на провал. Это просто расходится с реальностью.
Возможно, Go далеко не лучший язык для написания раздутого гигантского монолита, да. Но он отличен для создания распределенных систем, наверняка использующих SOA дизайн, кодовые базы которых при этом остаются достаточно гибкими для роста, рефакторинга и работы больших групп программистов.