Забыли ещё цитаты про прекрасное решение - if err != nil { ... }. )
Да, в C#, например, можно запихнуть всё в один большой try … catch … блок и быть счастливым по этому поводу. При этом вся логика обработки ошибок будет жить в одном или нескольких catch блоках.
Пишу переодически на Go в прод, и понимаю что как хоршо когда ты все же можешь быть счастлив.))
Будут доставать но в существенно меньшем кол-ве и не все захотят этим заниматься.
Возможно лучшим будет комбинированный подход. Тотальный запрет - только по рецепту и одновременное просвещение. Но в РФ соловьиный уже применяют для других целей, трудно будет направить его в благое русло.)
Возрастом/опытом воспоминания о том что ты писал "красивый" код остаются, но когда смотришь на код таких же каким ты был N-лет назад, почему то он уже не кажется красивым.))
По моей статистике, самые ужасные сотрудники это парни до 30 лет. Потому что нужно в каждом слове доказать что ты лучше, прикрутить новую технологию которая показалась лучше, что бы опять же доказать что ты лучше, мышление шаблонное - то что сказали авторитетные люди(хотя после оно не уходит, просто человек становится покорнее и спокойнее). А самое главное это кому нужно это решение бизнес задач - главное что-то крутое написать в коде, при чем каждый автор по своему понимает слово, крутое.) Поэтому если у вас продукт и нужно решать проблемы а не перепродавать человеко часы, лучше взять девушку или парня который уже успокоился. :)
Добрый день проблема не в самой концепции тэйтов, а в том что разработчики её используют без всякой меры. Эту проблему вижу в каждом проекте. Trait'ы инструмент для специфических случаев, но типичный разработчик приступая к решению очередной задачи думает не как решить её наиболее простым и очевидным для других способом, а как по максимому использовать все возможности предоставляемые Tatait'ами. Как итог существенное усложнение кода.
По этому я и написал что "Разработчики заложили в язык бомбу".
Все это я уже видел на примере Scala в итоге бизнес отказывается от языка. Потому что при аналогичном с другими ЯП результате, издержек много - проект сложнее, кадры найти трудно, фичи выкатываются дольше.
Касаемо Option/Result, все что вы написали справедливо. Но дело в другом. Проще написать try/catch нужном выше по стэку и перехватить любу ошибку снизу, не проверяя пробросили вы Option на верх или где то забыли. Бесплатно получить трассировку стэка с подробной ифнормацией об ошибке. Все это за вас делает компилятор. Пока я не видел проблем при преминении концепции try/catch, код работает стабильно на всех языка что писал. А поскольку try/catch требует существенно меньше усилий от программиста, я предпочитаю для себя его, а оставшиеся силы направляю на решение прикладных вопросов.
Мой подход заключается в том что бы написать максимально простой и компактный код, который работает только в определнном состоянии а если где то возникает не ожидаемая ситуация то завершить выполнение проблемной ветки кода аварийно. И потом разбираться почему так произошло. Как результат ПО работает стабильно, понятно и быстро пишется. Свободное время я больше на решение бизнес задачи или на себя.)
Если вы строку оборачиваете в Path как это решает проблему? Все равно в типе Path будет лежать строка. Т.е. по сути проблема оборачивается, но не решаете. Как вы считаете это так или я допускаю ошибку?
Про библиотеки. Не имел ввиду что в популярных библиотеках используют unwrap, про unwrap было написано в контексте о прикладном коде. В библиотеках что я видел как раз код пронизан Option/Result и д.р. монадами, почти в каждой функции есть паттерн матчинг.
Используя try/catch код каждой функции можно сократить. Вы уже по умолчанию работаете с корректным значением, а если где то возникнет ошибка выше по коду вы её перехватываете выше по коду в том месте где посчитаете нужным с точки зрения логики вашей программы.
Использование unwrap это типично для прикладного кода, в данном случае я рассматриваю реальную практику применения которую наблюдаю. Поэтому и вызывает сомнение польза такой фичи. Это то же самое что доказывать - в Си есть free а значит проблем с утечкой памяти там быть не должно, а то что разработки забывают или забивают на free проблема конкретного проекта.
Скорее будет проблема если вы заключите "соглашение о неконкуренции" в некоторых странах это законно. И вероятно вас могут просто не взять в некоторый стартап/компанию занимающийся специфической узкой темой, без подписания подобного договора. Возможно только если вы не какой то уже очень ценный специалист который может себе позволить торговаться.
Хотел бы с вами не согласиться. Все зависит от тематики. Если например про API некоторой платформы тогда действительно проще читать текст в виде документации. В том же IT для новичнок видео уроки с примерами как человек запускает среду и начинает программировать могут быть весть полезны т.к. показывают процесс вживую со всеми мелочани аналогично тому что вам обьясняет более опытный коллега, сидя рядом.
Если взять не столь специфическую тему как IT, во всяком случае это так для возможно 99% населения земли:), например тему строительства. То видео уроки намного лучше текста, потому что очень много операций который сложно описать в виде текста так что бы стало ясно, зато по видео все одназначно. При этом текст может быть удобен для некоторых других подзадач в виде перечисления списка материалов и т.п. Я сам больше смотрю по теме стройки или сада.
Поэтому может и не стоит сгущать краски. Просто большая часть тем которые интересуют обычных пользователей проще воспринимается в формате видео со звуком.) Тем более если это развлекательный контент.)
Касаемо try/catch могли бы разъяснить - почему это goto на стероида и если это так то чем он по сути отличается от паники.
Что касаемо Option/Result имею богатый опыт работы с подобными структурами 1.5 года коммерческой работы на Scala, различные pet проекты даже не буду упоминать. Более чем хорошо понимаю данные монады и как с ними работать.
На мой взгляд большинство программистов пришет unwrap потому что понимает - данные в норме, в этом месте, должны быть, а если их нет значит программа в некорректом состоянии, логичто в этом случае бросить панику(и т.п.), вторая причина - если все писать через map и т.п. то код очень сильно увеличивается в размере, пишется намного дольше, становиться сложнее для восприяти и рефакторинга. Это моя субьективная оценка, но имеются и обоснования, т.к. каждая из этих конструкций приносит дополнительную сложность в код, значит и общая сложность кода увеличивается. Становится ли он от этого более надежным, спорный момент лично я не обнаружил доказаться что это так.
Это все мне очень напоминает Scala, когда появилась был такой подъем энтузиазма. А когда начали применять в проде, оказалось что проекты пишутся в несколько раз дольше, падают также часто как на Java. Специалистов найти сложно потому что не многим по душе сражаться с типами.)
Спасибо за статью. Оставлю свое скромное мнение про Rust.)
Разработчики заложили в язык бомбу замедленного действия в виде Traits. К сожалению бесконтрольное применение Traits приводит к тому, что разработчики библиотек решая простейшие задачи стремятся по максимуму использоваться всесь потенциал Traits из-за этого интерфейс библиотек многократно переусложнен относительно решаемой задачи. Такая же проблема при разработке проектов. Когда смотришь на библиотеку на Си её исходный код прост и понятен. Когда изучаешь библиотеку на Rust тратишь на от х2 до х10 усилий более, существенно повышается количество wft/мин. )) Тут дело не в том что я не понимаю generic код, а скорее в том что там где нужно передать массив байт и вернуть флаг ок/err, нет необходимости писать N дополнительных Traits. Мне кажется нас ещё ждет язык с разумным балансом между с одной стороны откровенным примитивизмом go и переусложенным в Rust.
Второй момент который не понравился, это работа с ошибками. Казалось бы Option/Result благое намерение но большинство кода , что я видел, выглядит как бесконечное unwrap(), это конечно лучше чем go в котором код на 50% состоит из if err != nil { panic(..)/return err }. Но все же непонятно зачем делать фичу которую большинство разработчиков не будут использовать. Тем более что есть богатый опыт других языков включающих это, и там проблемы аналогичные. Касаемо panic. Не мог понять в go, так и в rust не могу зачем делать такую неудобную реализацию обратоки ошибок, когда уже сущесвует подход с try/catch, чем паника отличается по сути от exception кроме существенно менее удобного синстаксиса работы с ней, может кто ни будь пояснит?
Если вы с чем то не согласны, жду ваших конструктивных замечаний или предложений.)
Ну почему же, придумали - когда не пишешь монады то существенно лучше, главное проще. ))
Так все таки раздел произошел на пифагоре или египтянах?)
Аристотель, первым из известных описал базовые законы логики. Вот где все начинается!
А ведь программирование полностью построено на Булевой логике, в которой формализованы логические законы. Не будем забывать и Джорджа Буля.
Забыли ещё цитаты про прекрасное решение - if err != nil { ... }. )
Пишу переодически на Go в прод, и понимаю что как хоршо когда ты все же можешь быть счастлив.))
На мой вкус монады это ещё тот сорт грязи, замаскированный в красивую обертку. :)
Будут доставать но в существенно меньшем кол-ве и не все захотят этим заниматься.
Возможно лучшим будет комбинированный подход. Тотальный запрет - только по рецепту и одновременное просвещение. Но в РФ соловьиный уже применяют для других целей, трудно будет направить его в благое русло.)
Видимо на тех которые по умолчанию делают код чистым.)
Покажите скорее этот язык!)
Возрастом/опытом воспоминания о том что ты писал "красивый" код остаются, но когда смотришь на код таких же каким ты был N-лет назад, почему то он уже не кажется красивым.))
А вообще раньше и трава была зеленее..)
По моей статистике, самые ужасные сотрудники это парни до 30 лет. Потому что нужно в каждом слове доказать что ты лучше, прикрутить новую технологию которая показалась лучше, что бы опять же доказать что ты лучше, мышление шаблонное - то что сказали авторитетные люди(хотя после оно не уходит, просто человек становится покорнее и спокойнее). А самое главное это кому нужно это решение бизнес задач - главное что-то крутое написать в коде, при чем каждый автор по своему понимает слово, крутое.)
Поэтому если у вас продукт и нужно решать проблемы а не перепродавать человеко часы, лучше взять девушку или парня который уже успокоился. :)
Добрый день проблема не в самой концепции тэйтов, а в том что разработчики её используют без всякой меры. Эту проблему вижу в каждом проекте. Trait'ы инструмент для специфических случаев, но типичный разработчик приступая к решению очередной задачи думает не как решить её наиболее простым и очевидным для других способом, а как по максимому использовать все возможности предоставляемые Tatait'ами. Как итог существенное усложнение кода.
По этому я и написал что "Разработчики заложили в язык бомбу".
Все это я уже видел на примере Scala в итоге бизнес отказывается от языка. Потому что при аналогичном с другими ЯП результате, издержек много - проект сложнее, кадры найти трудно, фичи выкатываются дольше.
Касаемо Option/Result, все что вы написали справедливо. Но дело в другом. Проще написать try/catch нужном выше по стэку и перехватить любу ошибку снизу, не проверяя пробросили вы Option на верх или где то забыли. Бесплатно получить трассировку стэка с подробной ифнормацией об ошибке. Все это за вас делает компилятор. Пока я не видел проблем при преминении концепции try/catch, код работает стабильно на всех языка что писал. А поскольку try/catch требует существенно меньше усилий от программиста, я предпочитаю для себя его, а оставшиеся силы направляю на решение прикладных вопросов.
Мой подход заключается в том что бы написать максимально простой и компактный код, который работает только в определнном состоянии а если где то возникает не ожидаемая ситуация то завершить выполнение проблемной ветки кода аварийно. И потом разбираться почему так произошло. Как результат ПО работает стабильно, понятно и быстро пишется. Свободное время я больше на решение бизнес задачи или на себя.)
Если вы строку оборачиваете в Path как это решает проблему? Все равно в типе Path будет лежать строка. Т.е. по сути проблема оборачивается, но не решаете. Как вы считаете это так или я допускаю ошибку?
Про библиотеки. Не имел ввиду что в популярных библиотеках используют unwrap, про unwrap было написано в контексте о прикладном коде. В библиотеках что я видел как раз код пронизан Option/Result и д.р. монадами, почти в каждой функции есть паттерн матчинг.
Используя try/catch код каждой функции можно сократить. Вы уже по умолчанию работаете с корректным значением, а если где то возникнет ошибка выше по коду вы её перехватываете выше по коду в том месте где посчитаете нужным с точки зрения логики вашей программы.
Использование unwrap это типично для прикладного кода, в данном случае я рассматриваю реальную практику применения которую наблюдаю. Поэтому и вызывает сомнение польза такой фичи. Это то же самое что доказывать - в Си есть free а значит проблем с утечкой памяти там быть не должно, а то что разработки забывают или забивают на free проблема конкретного проекта.
Скорее будет проблема если вы заключите "соглашение о неконкуренции" в некоторых странах это законно. И вероятно вас могут просто не взять в некоторый стартап/компанию занимающийся специфической узкой темой, без подписания подобного договора. Возможно только если вы не какой то уже очень ценный специалист который может себе позволить торговаться.
Хотел бы с вами не согласиться. Все зависит от тематики. Если например про API некоторой платформы тогда действительно проще читать текст в виде документации. В том же IT для новичнок видео уроки с примерами как человек запускает среду и начинает программировать могут быть весть полезны т.к. показывают процесс вживую со всеми мелочани аналогично тому что вам обьясняет более опытный коллега, сидя рядом.
Если взять не столь специфическую тему как IT, во всяком случае это так для возможно 99% населения земли:), например тему строительства. То видео уроки намного лучше текста, потому что очень много операций который сложно описать в виде текста так что бы стало ясно, зато по видео все одназначно. При этом текст может быть удобен для некоторых других подзадач в виде перечисления списка материалов и т.п. Я сам больше смотрю по теме стройки или сада.
Поэтому может и не стоит сгущать краски. Просто большая часть тем которые интересуют обычных пользователей проще воспринимается в формате видео со звуком.) Тем более если это развлекательный контент.)
Спасибо за ответ.
Касаемо try/catch могли бы разъяснить - почему это goto на стероида и если это так то чем он по сути отличается от паники.
Что касаемо Option/Result имею богатый опыт работы с подобными структурами 1.5 года коммерческой работы на Scala, различные pet проекты даже не буду упоминать. Более чем хорошо понимаю данные монады и как с ними работать.
На мой взгляд большинство программистов пришет unwrap потому что понимает - данные в норме, в этом месте, должны быть, а если их нет значит программа в некорректом состоянии, логичто в этом случае бросить панику(и т.п.), вторая причина - если все писать через map и т.п. то код очень сильно увеличивается в размере, пишется намного дольше, становиться сложнее для восприяти и рефакторинга. Это моя субьективная оценка, но имеются и обоснования, т.к. каждая из этих конструкций приносит дополнительную сложность в код, значит и общая сложность кода увеличивается. Становится ли он от этого более надежным, спорный момент лично я не обнаружил доказаться что это так.
Это все мне очень напоминает Scala, когда появилась был такой подъем энтузиазма. А когда начали применять в проде, оказалось что проекты пишутся в несколько раз дольше, падают также часто как на Java. Специалистов найти сложно потому что не многим по душе сражаться с типами.)
Спасибо за статью. Оставлю свое скромное мнение про Rust.)
Разработчики заложили в язык бомбу замедленного действия в виде Traits. К сожалению бесконтрольное применение
Traits приводит к тому, что разработчики библиотек решая простейшие задачи стремятся по максимуму использоваться всесь потенциал Traits из-за этого интерфейс библиотек многократно переусложнен относительно решаемой задачи. Такая же проблема при разработке проектов. Когда смотришь на библиотеку на Си её исходный код прост и понятен. Когда изучаешь библиотеку на Rust тратишь на от х2 до х10 усилий более, существенно повышается количество wft/мин. ))
Тут дело не в том что я не понимаю generic код, а скорее в том что там где нужно передать массив байт и вернуть флаг ок/err, нет необходимости писать N дополнительных Traits.
Мне кажется нас ещё ждет язык с разумным балансом между с одной стороны откровенным примитивизмом go и переусложенным в Rust.
Второй момент который не понравился, это работа с ошибками.
Казалось бы Option/Result благое намерение но большинство кода , что я видел, выглядит как бесконечное unwrap(), это конечно лучше чем go в котором код на 50% состоит из if err != nil { panic(..)/return err }. Но все же непонятно зачем делать фичу которую большинство разработчиков не будут использовать. Тем более что есть богатый опыт других языков включающих это, и там проблемы аналогичные.
Касаемо panic. Не мог понять в go, так и в rust не могу зачем делать такую неудобную реализацию обратоки ошибок, когда уже сущесвует подход с try/catch, чем паника отличается по сути от exception кроме существенно менее удобного синстаксиса работы с ней, может кто ни будь пояснит?
Если вы с чем то не согласны, жду ваших конструктивных замечаний или предложений.)