Странно, а я ставил весной как раз кондей Tuvio и ненарадуюсь (сейчас вот как раз подумываю о холодильнике их же бренда 335л который), по соотношению цена/качество вообще имба. Фреон кстати в нем есть, это и в инструкции написано и по факту, у вас какая модель?
>Но на этом уровне LLM — враг, а не помощник. От вас ожидаются свежие идеи, а не пережеванный силос, срыгнутый средними разработчиками в публичное пространство.
А почему просто не использовать табличку на kafkaengine + материализованная вью которая будет вставлять в целевую табличку? В чем конкретный плюс redpanda
я выше уже писал, мне чтоб полюбить if err!=nil понадобилось наверное лет 5-6, использования го как основного языка и должен сказать у этого подхода есть определенные плюсы
Как минимум, не возникает сложных и скрытых механизмов обработки ошибок, магии которую легко создать эксепшенами. Вместо этого ошибки - обычные значения, которые можно проверять и обрабатывать явно. Поведение становиться более очевидным
С точки зрения читаемости if err != nil делает обработку ошибок явной и легко заметной. Ошибки не “заглушаются” и не остаются незамеченными (ну в идеале)
В целом такая обработка ошибок это фича дизайна языка - сознательное решение, направленное на упрощение кода, увеличение его читаемости и контроль предсказуемости.
вопрос здравого смысла, если с используется только строкой-двумя ниже, то это подходящее имя, если строками пятью ниже и больше то уже есть смысл в cnt или count
>Поэтому уважайте тех кто придёт за вами
В том и смысл,краткость (там где она уместна) и нужна для ясности, чтоб читающему было удобнее, не нужно задерживаться взглядом на каждой yetAnotherVar,
>Детализация может казаться излишней писателю, так как для него всё очевидно
Детализация должна быть уместной и не нарушать лаконичность, излишняя детализация, там где она не нужна, ухудшит читаемость, мы же в первую очередь заботимся именно о читающем.
Я понимаю вашу позицию, и во многом вы правы, сам я до этого очень долго писал на php/java/delphi/python и привык считать говорящие имена хорошим тоном, но стоит сказать, что за последние годы скорректировал свою позицию в сторону более взвешенной - краткость, там где она к месту, прекрасна. А бездумным применением практик - можно любой подход дискредетировать
Касаемо обработки ошибок, ну мне уже трудно сказать - сначала подход казался непривычным и не очень удобным, сейчас после почти 10 лет на go, он для меня уже как родной, у него есть свои плюсы
когда ждать?)
Лично по моим ощущениям, стоило бы еще подержать в экспериментал и допилить реализацию
Странно, а я ставил весной как раз кондей Tuvio и ненарадуюсь (сейчас вот как раз подумываю о холодильнике их же бренда 335л который), по соотношению цена/качество вообще имба. Фреон кстати в нем есть, это и в инструкции написано и по факту, у вас какая модель?
Честно говоря, ждал, что в статье будет о том, как оно работает под капотом
>Но на этом уровне LLM — враг, а не помощник. От вас ожидаются свежие идеи, а не пережеванный силос, срыгнутый средними разработчиками в публичное пространство.
Вот это просто прекрасно
Мы не так давно на 1.24 перешли в проде, после выхода первого патча только, всему свое время =)
Ну спасибо)))) А по сути, претензии есть?
P.S. случайно плюсанул коммент
И Кокс...
>В связи с тем, что DataGrip больше не доступен
А что с ним случилось? Вроде все работает
>На данный момент это действительно ограничивает мою работу
Поржал с этого =) Зп пусть тоже AI тогда переводит
А почему просто не использовать табличку на kafkaengine + материализованная вью которая будет вставлять в целевую табличку? В чем конкретный плюс redpanda
НУ росатом имеет хорошую репутацию - от роскосмоса такой новости я бы только нервно улыбнулся
Честно говоря, раccчитывал на что то более оригинальное, статья опоздала лет на 15, примерно
где то с офисе docker
Скажем так, он был мне непривычен и я не сразу понимал все его плюсы
ну и это тоже, да и момент с производительностью, исключения требуют дополнительной нагрузки на систему (например, из-за управления стеком).
цифры в именах переменных это мрак, конечно, очень давно такого не видал
я выше уже писал, мне чтоб полюбить if err!=nil понадобилось наверное лет 5-6, использования го как основного языка и должен сказать у этого подхода есть определенные плюсы
Как минимум, не возникает сложных и скрытых механизмов обработки ошибок, магии которую легко создать эксепшенами. Вместо этого ошибки - обычные значения, которые можно проверять и обрабатывать явно. Поведение становиться более очевидным
С точки зрения читаемости if err != nil делает обработку ошибок явной и легко заметной. Ошибки не “заглушаются” и не остаются незамеченными (ну в идеале)
В целом такая обработка ошибок это фича дизайна языка - сознательное решение, направленное на упрощение кода, увеличение его читаемости и контроль предсказуемости.
вопрос здравого смысла, если с используется только строкой-двумя ниже, то это подходящее имя, если строками пятью ниже и больше то уже есть смысл в cnt или count
>Поэтому уважайте тех кто придёт за вами
В том и смысл,краткость (там где она уместна) и нужна для ясности, чтоб читающему было удобнее, не нужно задерживаться взглядом на каждой yetAnotherVar,
>Детализация может казаться излишней писателю, так как для него всё очевидно
Детализация должна быть уместной и не нарушать лаконичность, излишняя детализация, там где она не нужна, ухудшит читаемость, мы же в первую очередь заботимся именно о читающем.
Я понимаю вашу позицию, и во многом вы правы, сам я до этого очень долго писал на php/java/delphi/python и привык считать говорящие имена хорошим тоном, но стоит сказать, что за последние годы скорректировал свою позицию в сторону более взвешенной - краткость, там где она к месту, прекрасна. А бездумным применением практик - можно любой подход дискредетировать
Касаемо обработки ошибок, ну мне уже трудно сказать - сначала подход казался непривычным и не очень удобным, сейчас после почти 10 лет на go, он для меня уже как родной, у него есть свои плюсы
любопытно, разовьете мысль?