Да, это более явно/очевидно. Но не менее громоздко. И понять где случилась ошибка не так уж трудно? Есть же stack trace.
По своему опыту не помню вообще никаких особых проблем с try/catch и определением где именно произошло исключение. Практически всегда есть трейс который прямо говорит что вот в таком то файле, на такой-то строке возникло такое-то исключение
Подход в го дисциплинирует, но вот назвать его менее громоздким что-то сложно
Если пытаться писать «как в Java» с try/catch или тащить Python‑подходы, код превращается в громоздкие обёртки и цепочки ошибок, из‑за чего теряется главное преимущество Go — прозрачность и лёгкость сопровождения.
Честно говоря не замечал что из-за try/catch код превращается во что-то более громоздкое чем обработка ошибок в go...
Код можно поправить и даже иногда не сильно сложно... А вот если таблица называется zakaz или tranzakciya, вот это боль...
А вот это смешно )
Класс. Вот бы ещё это всё нормально работало.
Да? Надо попробовать. Просто показалось что слишком многое надо руками делать.
Как-то в go эти DI выглядят ущербно.
Как-будто это вообще не то. Паттерн для клиент-серверного взаимодействия.
Если ошибки не влияют на ветвление логики, может они вообще тогда не нужны...
Неплохая идея была...
Вейланд? Можно попробовать x11, возможно будет веселее
Хорошая статья, спасибо за перевод.
Выглядит так, что проще все таки было бы redis завести =))
сдается мне что новичку будет гораздо сложнее освоить spring ))))))
Да, это более явно/очевидно. Но не менее громоздко. И понять где случилась ошибка не так уж трудно? Есть же stack trace.
По своему опыту не помню вообще никаких особых проблем с try/catch и определением где именно произошло исключение. Практически всегда есть трейс который прямо говорит что вот в таком то файле, на такой-то строке возникло такое-то исключение
Подход в го дисциплинирует, но вот назвать его менее громоздким что-то сложно
Честно говоря не замечал что из-за try/catch код превращается во что-то более громоздкое чем обработка ошибок в go...
Спасибо! Обязательно попробую все варианты
На мой взгляд задачка прямо скажем не простая.
Сорян что спрашиваю, пока плохо в этом разбираюсь.
А если добавить defer close(ch) ?
Как буферизованный канал спасёт от утечки?
Привет, а можешь объяснить по поводу медленной функции. Почему в случае не буферизованного канала может возникнуть deadlock? Никак понять не могу
Абсолютно так же мысль возникла и вопрос - неужели так принято в nestjs?
Интересно почему такая шумиха именно вокруг it, есть же много других специальностей попроще, где AI может себя проявить не хуже?
Не понятно. Почему в среднем? То есть какие-то операции выполняются быстрее?