Здравствуйте, Sheridan, Вы писали:

S> Моё отношение — прикольная штука, но противоречивая.

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

Для своей ниши и своего времени язык практически идеален. И более того, уделывает в своей нише (web, console) практически всех левым мизинцем.

Здравствуйте, Pzz, Вы писали:

Pzz> Пайк где-то писал, что форматирование в Go не нравится никому, но наличие единого стиля форматирования нравится всем.

А мне нравится. И форматирование и то, что оно едино. Правда одно невозможно без другого. Наконец-то можно забить на tab vs space, CamelCase vs Snake case (стандартный линтер не ругается => идите лесом), количество отступов и вот это все и сосредоточиться на бизнес-задачах.

LVV>Не. Одну скобку можно потерять на счет раз.
LVV>В отличие от ключевого слова.

Да все это вопрос привычки. Вместо открывающей скобки может использоваться что-то специфичное, скажем, ключевое слово of:

case get_something() of
  1 -> do_one();
  Many when Many < 100 -> do_many();
  TooMany -> throw("that was too many")
end.

S>В примере catch нужен для логов, кмк.

В том-то и дело что не нужен. Пусть летит себе дальше, до того уровня, где может быть обработана. В процессе пролета будет накоплен стек, так что когда исключение наконец-то поймано, есть вся необходимая информация.

Здравствуйте, Anton Batenev, Вы писали:

Pzz>> Пайк где-то писал, что форматирование в Go не нравится никому, но наличие единого стиля форматирования нравится всем.

AB>А мне нравится. И форматирование и то, что оно едино. Правда одно невозможно без другого. Наконец-то можно забить на tab vs space, CamelCase vs Snake case (стандартный линтер не ругается => идите лесом), количество отступов и вот это все и сосредоточиться на бизнес-задачах.

Тебе нравится наличие единого стиля, а не конкретно этот стиль. Ну, во всяком случае описываешь ты именно это.

Здравствуйте, LaptevVV, Вы писали:

LVV>Не. Одну скобку можно потерять на счет раз.
Разве что если лепить их к коду а не на отдельную строку

Здравствуйте, Pzz, Вы писали:

Pzz>Надо не языки переусложнять
Переусложнять не надо но и переупрощать не надо.

Pzz> а требовать повышения зарплаты в 5 раз.
И губозакаточную машинку

Pzz> Вот создать профсоюз и требовать.
Профсоюзы — зло.

Здравствуйте, Sheridan, Вы писали:

CC>>Это далеко не всегда реализуемо.
S>Было бы желание.
И килотонны денег...

CC>>В разы дешевле не трогать то, что работает.
S>Ой, сильно черевато жестоким крахом в будущем, когда таки потрогать придётся.
Зависит.

Здравствуйте, SkyDance, Вы писали:

SD>Мне при виде такого сразу хочется руки оторвать тем, кто не понимает, что такое "обработка ошибок".
Ну давай, покажи класс: большой стек вылетел потому что где то в глубине сибирских руд pread вернул ENOENT.
Где, какой, что делалось, что читалось, зачем?

SD>Если так уж вышло, что только на самом верху ошибку можно обработать, то именно там и надо ставить catch.
И протерять все внутренние состояния, которые ой как нужны когда всё что до тебя долетело это обугленные и дымящиеся ошмётки жопы пользователя логи.

Здравствуйте, SkyDance, Вы писали:

SD>В процессе пролета будет накоплен стек
Этого крайне мало. Надо куда больше контекста.
Более того сие нихрена не работает в компилируемых языках с оптимизаЙцией и инлайнингом.

SD> так что когда исключение наконец-то поймано, есть вся необходимая информация.
Да хрен там плавал.

Здравствуйте, vsb, Вы писали:

vsb>А во всех остальных местах просто return err
Удачного триажа!

Здравствуйте, CreatorCray, Вы писали:

CC>>>Это далеко не всегда реализуемо.
S>>Было бы желание.
CC>И килотонны денег...
Зеттатонны, ага, да.

CC>>>В разы дешевле не трогать то, что работает.
S>>Ой, сильно черевато жестоким крахом в будущем, когда таки потрогать придётся.
CC>Зависит.
От того, насколько прокачана удача.

Здравствуйте, Sheridan, Вы писали:

Когда я читаю обзорную статью про Go, я к нему очень хорошо отношусь. Всё круто, дайте две. А когда я открываю примеры с кодом, тут у меня вся любовь быстро проходит, в т.ч. из-за синтаксиса.

Жалею, что не прижился майкрософтовский подход, когда котлеты (системы с идеями типа .Net) были отдельно, а мухи (ЯП от VB до Nemerle) — отдельно.

Pzz>Например, когда в Go из слайса делается сабслайс, они разделяют общую память. Потом, если к исходному слайсу сделать append, он может среаллоцироваться, и тогда память разделится. А может и не среаллоцироваться, если у него места в хвосте было достаточно припасено.

Pzz>Или вот, к примеру, если из слайса по-наивному сделать очередь, добавляя элементы в конце и забирая в начале, все на вид будет вполне работать. Но только выделенная под это дело память будет всегда расти и никогда не освобождаться. Так можно гигабайт, например, сожрать, не заметив. Особенно если делать это неторопясь.

Хм, но это документированное поведение?

Pzz>Или, к примеру, если ты добавляешь записи в map, но забываешь их оттуда удалять. Они ж сами никуда не исчезнут и будут занимать память. Так можно сделать утечку памяти в языке со сборщиком мусора. В Питоне так тоже можно, кстати. И в JS.

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

CC>Ну давай, покажи класс: большой стек вылетел потому что где то в глубине сибирских руд pread вернул ENOENT.

На вершине этого стека уже есть информация о том, что за файл читается. Если, скажем, это какой-нибудь RPC, там известно, куда лезут и зачем.

CC>И протерять все внутренние состояния

Ты хочешь сказать, что у тебя все функции по стеку вызывают side effects? Пишут во всякие там глобальные переменные, и прочие stateful штуки? Так что если ты retry-ишь, результат совсем иной получается? Коли это так, то, знаешь, у тебя есть более серьезные проблемы, чем протеря внутренних состояний.

А если функции таки чистые (pure), то все внутренние состояния воспроизводятся прямо из input'а — как-то, имени файла, на который будет сказано ENOENT.

В целом же все логично: если код с самого начала грязный (not pure, ага), то неудивительно, что в него приходится пихать еще больше грязи на тему запоминания внутренних состояний в процессе пролета исключения вверх. Вот только назвать это хорошей программой... ну, я б не рискнул. Разве что если там какие-то сурово-жесткие ограничения на память, CPU или еще что, когда приходится что-то приносить в жертву.

Здравствуйте, SkyDance, Вы писали:

SD>На вершине этого стека уже есть информация о том, что за файл читается. Если, скажем, это какой-нибудь RPC, там известно, куда лезут и зачем.
Хрен там.

SD> Пишут во всякие там глобальные переменные
Ты забываешь про диск, сеть, shared memory, etc

SD>Так что если ты retry-ишь, результат совсем иной получается?
Лехко! Файл не локальный, какой файл надо открывать выясняется в результате RPC, и за ним лезут куда то в SAN через NFS. Куда именно — знает только функция дайте_мне_чего_то_там у себя внутри. И если не ловить и не логить внутри неё ошибки промежуточных стадий с контекстом этих самых стадий то наверх прилетит только "нишмагла" от чего пользы никакой совершенно.

SD>А если функции таки чистые (pure)
Т.е. ошибка таки ловится на каждой подфункции а не где то вверху со всех скопом?

SD>имени файла, на который будет сказано ENOENT.
Не на имя файла а конкретно из pread, реальный случай межжупрочим.

S>Моё отношение — прикольная штука, но противоречивая.

Да.
Писать на нем серверную часть с api для веба — довольно просто. Еще и встроенный веб-сервер — это тоже полезно.

Но есть и минусы:
— наркоманский синтаксис (как самого языка, так и многих функций стандартных либ)
— собрать на нем полезное приложение, которое из исходников просто компилируется и просто работает (без всяких там лазаний в интернет в процессе сборки) — не такая простая задача.

Здравствуйте, m2user, Вы писали:

Pzz>>Или вот, к примеру, если из слайса по-наивному сделать очередь, добавляя элементы в конце и забирая в начале, все на вид будет вполне работать. Но только выделенная под это дело память будет всегда расти и никогда не освобождаться. Так можно гигабайт, например, сожрать, не заметив. Особенно если делать это неторопясь.

M>Хм, но это документированное поведение?

Конечно.

Pzz>>Или, к примеру, если ты добавляешь записи в map, но забываешь их оттуда удалять. Они ж сами никуда не исчезнут и будут занимать память. Так можно сделать утечку памяти в языке со сборщиком мусора. В Питоне так тоже можно, кстати. И в JS.

M>А что есть есть языки с автоматическим управлением памятью, где map ведет себя по другому?

Думаю, что нет.

Здравствуйте, Pzz, Вы писали:

Pzz> от обилия восклицательных знаков
Раст для девочек?

Pzz>Я пишу на нём системный софтварий.

Я недавно в теме про Carbon lang интересовался разработкой библиотек на Go с целью использования их из других ЯП.
И вроде как способ есть и с примерами, но судя по комментам есть какие-то препятствия?
https://rsdn.org/forum/flame.comp/8731366.1

Автор: pagid_
Дата: 14.04.24