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

Go предлагает уникальный и прямолинейный подход к обработке ошибок, отличающийся от try-catch в других языках. Он основан на явной проверке возвращаемых значений, что требует больших проверок, но ведет к более надежному коду. Рассмотрим основы, современные инструменты пакета errors и лучшие практики.

defer в Go — это мощный механизм для очистки ресурсов, закрытия файлов и разблокировки мьютексов. Вы наверняка слышали, что defer делает код чище и безопаснее.

Когда вы открываете файл через os.Open() или os.Create(), Go выделяет ресурс операционной системы — дескриптор файла.

Хочу сразу пояснить, что я лично пишу на Go уже около 10 лет и уходить от него не планирую. Но тем не менее мне интересно мнение других разработчиков, которые работают или работали с Go на больших проектах. Во многом я согласен с недостатками Go, описанными ниже, так как сам сталкиваюсь с этими проблемами и на не самых больших проектах. Вот мой перевод статьи.

Привет, Хабр!

Сегодня хочу поговорить о проблеме, которую многие недооценивают в своих Go-проектах. Речь пойдет о бессрочном select {}, который легко может привести к блокировке, утечке ресурсов и деградации производительности.

Рассказываю, какие недостатки традиционного подхода к конфигурации я увидел и как библиотека zerocfg может упростить жизнь разработчикам на Go.

Знакомый каждому сценарий: добавляем новую опцию, правим сразу несколько мест и... допускаем ошибку. Опечатки в тегах, забытые дефолтные значения, «мертвые» конфиги, которые годами живут в проекте, отнимая внимание и время. Звучит болезненно, правда?

Я решил, что хватит терпеть это, и вдохновился простотой стандартного пакета flag, где каждая опция — это буквально одна строка кода. Представьте: больше никакой беготни по структурам и файлам! В zerocfg вы объявляете опцию, дефолтное значение и документацию в одной строке — лаконично, понятно, надёжно.

Golang — приключение не на 20 минут, а игра вдолгую. Подтвердили это, собрав в офисе Lamoda спикеров Lamoda Tech, а также 2ГИС и МТС. Помимо новых докладов, разблокировали экспериментальный формат факап-разгонов, где наши друзья из ВИ.Tech, Orion soft и Cloud.ru вместе со зрителями делились историями провалов. Публикуем материалы с этой встречи.

После каждой новой статьи с заголовком «ООП — это обман» хочется напомнить: ООП — это не набор шаблонов из книжек, а инженерный подход. Если проект страдает от наследования и DI, возможно, проблема не в ООП. А в том, как вы его применяете.

Карты (maps) в Go — это отличный инструмент для хранения данных в виде пар «ключ — значение». Они широко используются в разработке благодаря своей гибкости и удобству. Например, карты часто применяются для кэширования данных, хранения конфигураций или обработки больших объемов информации. Однако эффективная работа с картами требует понимания их внутреннего устройства и особенностей управления памятью. Под капотом карты реализованы на основе хеш-таблиц, что обеспечивает быстрый доступ к данным, но также создает потенциальные проблемы, такие как неэффективное использование памяти или утечки. В этой статье мы разберем устройство карт в Go, рассмотрим, как они растут и работают, а также обсудим способы оптимизации их использования. Особое внимание уделено проблемам, связанным с инициализацией карт и управлением памяти, чтобы помочь вам писать более эффективный и надежный код.

Категорически приветствую, дорогой Хабр! Меня зовут Сергей и я психолог. Но не нужно хлопать и говорить «я тебя так понимаю» или «сочувствую». Я искренне люблю свою профессию. Одна из главных причин этой любви – возможность прикоснуться ко множеству жизней и понять размышления человека, его майндсет, если позволите. А также, увидеть, к чему этот майндсет привел – к каким достижениям и, разумеется, трудностям.

И по моим подсчетам, за последние три года я пообщался (как бы сказали любимые здесь всеми HR-ы: «провел глубинное интервью») примерно с сотней айтишников всех мастей. И вот замеченные закономерности и выводы мне хочется обобщить в этой статье. Фактически, это будет набор жизненных историй, переживаний и размышлений, которые достаточно трудно узнать в таком количестве и на таком уровне откровенности, не находясь в роли психолога. Впереди вас ждет квинтэссенция самых сокровенных мыслей, желаний и неудач ваших коллег по цеху, которые вам никогда об этом не расскажут. Поехали!

Хороших технических статей про Go было написано немало, и эта — не одна из них. Эта статья — графомания о моём субъективном и эмоциональном опыте перехода со Scala на Go.

^{Руководитель: Хочешь техлидить новый проект?}

^{Я: Да, конечно. А что за проект?}

^{Руководитель: Распределённые бэкенды на Go.}

^{Я: Go? Но я же скалист-функциональщик…}

^{Чуть позже}

^{Коллега: Слышал, что ты будешь техлидить другой проект — вы там тоже Scala завозить будете?}

^{Я: Нет, будем писать на Go.}

^{Коллега: Ты что, бросаешь Scala и нашу тусовку?!}

Этот момент мне запомнился очень хорошо. Когда ты долго работаешь с каким-то языком, накапливаешь экспертность, нюансы, грабли, привыкаешь жить в его экосистеме — смена стека кажется чем-то болезненным. Будто ты уезжаешь в другой город и оставляешь старых друзей.

Да, конечно же, язык — просто инструмент, а реальная компетенция — в теории, паттернах и опыте решения определённого рода задач, которые копятся за годы работы. Тяжело менять классы задач, но менять инструментарий гораздо легче...

Решил перейти на Go. Причина простая — видел вакансии с зарплатой выше 100 тысяч, и почти везде Go. Я до этого писал в основном на Python. Немного Django, немного микросервисов, WordPress. Закончил онлайн-школу, работаю уже третий год. Решил, что пора прокачиваться и становиться программистом-полиглотом.

Вот мой опыт и небольшие замечания по языку:

Многие из вас помнят, какими были IT-школы 10 лет назад. Это были просто сайты с полезными курсами по различным языкам программирования. Не было агрессивного маркетинга и обещаний звездных зарплат. Можно было с гордостью говорить о том, что ты прошёл какие-то курсы. Но главное — эти курсы действительно работали: после них удавалось устроиться на работу. Сейчас всё стало значительно хуже по всем направлениям. Перенасыщенный рынок, конкуренция между школами, вынужденная смена бизнес-модели, появление AI — всё это превратило IT-образование в то, каким мы видим его сегодня: в большой, неповоротливый и неэффективный организм с утраченной репутацией. Давайте разберёмся, как так получилось, и главное — что с этим делать.

На хабре и в остальном интернете хватает статей с критикой ООП. Кто-то ругает эту концепцию за излишнюю многословность, кто-то рассуждает о плохих аспектах ООП, кто-то сравнивает реализации ООП в разных языках.

После прочтения большинства этих статей и нескольких лет кодинга на C# я заявляю: «ООП - это один большой обман. Никто не понимает, что это такое. Люди просто говорят какие-то умные термины, их собеседники с умным видом кивают, хотя на деле трактуют эти же термины совершенно по-разному».

И вот почему.

Я «нанял» ChatGPT в кофаундеры — делюсь результатами, промптом, пятью масками и чек‑листом рисков, которые внедряются за вечер

Теперь всё, что раньше делали люди — создание курсов, проверку ответов, адаптацию персонализированных заданий — почти полностью взял на себя ИИ.

Duolingo — это уже давно не просто приложение с разноцветными совами и скучными заданиями. В 2025-м генеративный ИИ позволил Duolingo быстро создавать новые курсы, и за год почти удвоить число языковых курсов! Как им это удалось и что это значит лично для тебя — рассказываем подробнее...

Расскажу про свой опыт конфигурирования приложений, разобрав некоторые популярные библиотеки и примеры.

Друзья, всем привет, в последнее время в нашей среде завелась такая пикантная паника: "ИИ скоро заменит всех программистов, и мы станем не нужны!". Причём кричат так, будто бы уже завтра мы все проснёмся безработными. Но давайте вспомним, мы видели разные "замены" в IT: когда-то пугали, что калькуляторы заменят математиков, компьютеры — бухгалтеров, в 90-е уверяли, что языки высокого уровня отымут профессию разработчика, а сейчас нас пугают нейросетями. Одни предрекали, что low-code убьёт программистов, другие — что автоматизация заменит всех, но все эти прогнозы оказались преувеличением. Поэтому я встречаю такие пресказания скорее с интересом, а не с паникой.

Odin — это универсальный язык для системного программирования, придуманный Биллом Холлом aka «gingerBill». Odin задумывался как современная альтернатива C, и в нём делается акцент на простоте, производительности и удобочитаемости, но при этом не упускается контроль над низкоуровневыми деталями.

На сайте об этом языке Odin охарактеризован как «ориентированный на данные», именно поэтому в нём присутствуют, например, структуры массивов (SOA) и неявная инициализация значения в ноль. Удивительно, что, несмотря на такие приоритеты, в языке есть динамические словари и массивы, встроенные в сам язык. Притом, что памятью всё-таки приходится управлять вручную, такие встроенные вещи встречаются нечасто.

Возможно, вот те самые черты, придающие Odin собственный облик: язык задуман как эргономичный, такой, на котором удобно писать, и поэтому многое предоставляет «из коробки». Также в Odin предусмотрен «вендор», в котором содержатся привязки к разнообразным популярным библиотекам. Поэтому вкатываться в язык очень просто.

Архитектор редко работает в идеальных условиях. Бюджет ограничен, сроки поджимают, часть инфраструктуры устарела, часть команды работает удалённо. Всё это реальные ограничения, с которыми нужно уметь работать. А ещё, нужно уметь предсказывать различные риски.

Давайте постараюсь сформулировать советы, которые я дал бы самому себе, если бы возвращался назад, или тому, кто сейчас работает аналитиком, разработчиком или тестировщиком, и хочет двигаться в сторону архитектуры.