Привет! Я ex. Разработчик из VK, сейчас принял оффер от Ozon'a, и за последний месяц я прошел собеседования в 4х бигтех компаниях: Ozon, Avito, Wildberries и T-Bank и везде дошел до финалов/офферов. Пообщавшись во многих группах, посвященных Go-разработке, я понял, что много умных ребят готовясь к собесам не имеют четкой системы подготовки, и из-за этого заваливают технические собесы в компании. Не претендуя на истину в последней инстанции, предлагаю свою методику подготовки к собесам, которая помогла мне и моим знакомым подготовиться к техническим собесам во все популярные ру-бигтехи.

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

В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – Paxos, Raft и Zab – стали основой для построения отказоустойчивых систем. Они гарантируют, что при наличии кворума узлов (обычно большинства) все узлы придут к единому решению и последовательности операций, сохраняя консистентность данных. В данной статье мы рассмотрим устройство этих алгоритмов «под капотом», их этапы (выбор лидера, репликация журнала, обработка сбоев и восстановление), области применения в реальных системах (от координаторов в кластерах Kubernetes и Apache Kafka до распределённых баз данных), а также сравним готовые реализации (такие как etcd, ZooKeeper, Consul и др.) по ключевым характеристикам.

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

В этой статье разберёмся, зачем в Go существуют два способа создавать значения — make и new, чем они отличаются, как они работают и когда выбирать каждый из них.

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

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

Golang Top 15 ошибок

Go – язык простой, но из-за кажущейся простоты многие разработчики совершают одни и те же ошибки, которые приводят к серьёзным последствиям в production. Ниже собраны 20 самых распространённых ошибок при разработке на Golang и рекомендации по их исправлению.

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

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

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

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

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

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

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

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

Я прочитал статью Migrating away from Rust и хочу поделиться с вами своими мыслями, заодно переведя оригинал. Я буду вести повествование от своего лица, поскольку это скорее реакция и размышления, а не традиционный перевод.

Для меня тема весьма актуальна, так как я сам нахожусь в этом странном лагере разработки игр на нишевых движках. Я использую не Rust+Bevy, а Go+Ebitengine, но многие плюсы и минусы этих комбинаций интересно рассматривать как дополняющие друг друга.

Когда-нибудь, я обязательно напишу статью о своём опыте серьёзной разработки игр на Go, но пока я слишком сильно завертелся в рабочем процессе, чтобы успеть доделать демку своей игры до Steam Next Fest. Будет ли эта статья положительная, или это будет миграция на Godot? Кто знает!

Ну а пока, погнали разбирать статью.

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

В данной статье мы разберем несколько ключевых паттернов, связанных с микросервисами. Речь пойдет о паттернах миграции и интеграции (таких как Strangler Fig – «удушающее дерево» и API Gateway), о сетевых и структурных паттернах (Service Mesh, Sidecar), о шаблонах работы с данными (Database per Service, CQRS) и об особом подходе к хранению состояния (Event Sourcing). Для каждого паттерна мы рассмотрим его суть, назначение, примеры использования, а также плюсы и возможные сложности. К некоторым паттернам приведены упрощенные диаграммы и фрагменты кода, чтобы иллюстративно показать, как они работают на практике.

В данной статье представлен пошаговый процесс разработки легковесного веб-фреймворка на языке программирования Go. Основываясь на стандартной библиотеке net/http, мы исследуем ключевые концепции, лежащие в основе современных Go-фреймворков, таких как Gin, Echo и тд.

Привет, Хабр! Меня зовут Дмитрий Гурьянов, я руковожу командой Manuls в VK HR Tek (система ведения кадрового электронного документооборота). Сегодня расскажу о нюансах оптимизации на разных уровнях исполнения кода на Go.

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

Предлагаю разделить все возможные действия по оптимизации на группы по двум критериям: что мы оптимизируем и каким образом оптимизируем.

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

Чаще всего я настраивал это все на уровне кода, но, некоторый период назад наткнулся на Modelfile и решил изучить и попробовать его, в ходе экспериментов наткнулся на реально большое число неожиданностей и решил таки написать о нем тут подробнее :)

Modelfile позволяет упаковывать модели и формировать готовых агентов. В нем оказалось много реально неожиданного поведения, и одновременно с этим есть сложности и странности. Однако с его помощью можно взять множество разных моделей из того же Hugging Face и запустить под Ollama, а самое важное, удобства в тюнинге (или же наоборот отупливании модели :D ).

В 2024 году я заработал первый миллион, продавая ассеты на UE Marketplace, а в 2025 проверяю их актуальность в эпоху ИИ. Зовут Меня Хамзат, в UE с 2019 года.

В предыдущей статье я попросил — «Расскажите, зачем вам DI‑контейнер в golang». Большое спасибо всем, кто оставил коммент и проголосовал. Общий вывод такой: используем контейнер, потому что с ним удобно писать тесты. Тесты — весомый аргумент, особенно в контексте того, что тест — это часть кода. Получается, мы все таки «тащим» Di‑контейнер в проект. Ну, хорошо....

Вероятно, это будет uber‑fx, ведь у него хорошая документация, самое простое и понятное API по сравнению с другими..., или нет — не «тащим»?

Мой ответ — нет, uber‑fx не «тащим», потому что можно еще проще и понятнее.

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

Сегодня я хочу поговорить о том, как мы все иногда очарованы показателями тестового покрытия в Go — и как же часто эти проценты лукаво нам подмигивают. Казалось бы, влепили go test -cover, получили любимые цифры, приближающиеся к 100%, и можно выдохнуть. Но, увы, не всё так радужно, как хочется. На самом деле заветная сотка покрытия далеко не всегда означает, что ваш код действительно покрыт тестами.