Go *

Обработка ошибок — это один из самых важных аспектов написания надёжного кода. В Go к этому вопросу подошли нестандартно: вместо традиционного механизма try/catch, как в Java или Python, ошибки просто возвращаются как значения. Изначально это может показаться странным, но на практике этот подход делает обработку ошибок более явной и честной.

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

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

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

Я считаю, что при работе с Go в контексте нашей отрасли внедрение зависимостей (dependency injection, DI) часто имеет плохую репутацию из-за DI-фреймворков. Но сама по себе DI как техника довольно полезна. Просто её объясняют слишком большим количеством ОО-жаргона, что приводит к ПТСР у тех, кто перешёл на Go, чтобы сбежать из культа банды четырёх.

Знаю, что тема уже изъезжана вдоль и поперек, но я хотел бы поделиться своим видением Open/Close Principle из всеми любимым SOLID подходу к построении архитектуры софта. Ведь дядюшка Боб херни не посоветует, все таки опыта ему не занимать, поскольку он с 70х годов в разработке и знает базу, что нам и нужно. Да современный софт ушел далеко от того какой он был в 70-х, когда писали логические цепочек на перфокартах, делая дырки в картоне и компиляция занимала прямо прапорционально количеству этих самы карточек, где скорость выполнения считалась количеством символов в минуту. За все это время Дядюшка Боб собирал лучшие практики из которых и получились эти 5 принципов, которые помогут построить софт, который будет не так сильно с течением времени влиять на стоимость одной строки кода. (О чем он и пишет в своей книги «Чистая архитектура»).

Хочу отметить то, что есть мнение, что принципы SOLID — это про ООП и для языков, которые не следуют этой парадигме это не актуально, нет. Эти принципы построения архитектуры приложения не зависят от языка.

Если вы читали книгу «Чистая архитектуры» и дошли до Open/Close principle (SOLID) и из примера ничего не поняли, тогда вы пришли по адресу, поскольку я буду рассматривать именно этот пример. Для меня лично OCP это один из принципов, который заставляет продумывать архитектуру приложения, что очень важно.

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

Привет, Хабр! Меня зовут Александр Белышев. Хочу поделиться своим недавним опытом работы над RAG‑сервисом и думаю, что эта тема может быть интересна другим коллегам.

У меня на работе возникла задача по реализации RAG (Retrieval‑Augmented Generation) сервиса. Хотя без моего участия эту задачу успешно решили на Python, изучая их код я задумался: а как можно сделать что‑то подобное на Go?
Результатом этого исследования и моей работы стало следующее решение...

Чтобы понять, что решает synctest, мы должны сначала рассмотреть основную проблему: недетерминизм в конкурентных тестах.

func TestSharedValue(t *testing.T) {
    var shared atomic.Int64
    go func() {
        shared.Store(1)
        time.Sleep(1 * time.Microsecond)
        shared.Store(2)
    }()

    // Проверяем общее значение через 5 микросекунд
    time.Sleep(5 * time.Microsecond)
    if shared.Load() != 2 {
        t.Errorf("shared = %d, want 2", shared.Load())
    }
}

Этот тест запускает горутину, которая изменяет общую переменную. Она устанавливает shared в 1, спит 1 микросекунду, а затем устанавливает её в 2.

Тем временем основная функция теста ждёт 5 микросекунд перед проверкой того, достигло ли shared значения 2. На первый взгляд кажется, что этот тест должен всегда проходить. В конце концов, 5 микросекунд должно быть достаточно времени для завершения выполнения горутины.

Однако...

Очень часто автотесты воспринимаются как обременение: что-то скучное, унылое и совершенно не нужное. С уверенностью,  что вместо тестов лучше заняться «настоящим»  кодом, некоторые разработчики решают не тратить на них время… и тратят его в два раза больше, когда впоследствии приходится ковырять неожиданно возникшие ошибки. Факт: в долгосрочной перспективе именно тесты становятся фундаментом стабильности, а любое изменение без них превращается в настоящую игру с огнём — особенно в активно развивающемся проекте, когда каждый новый релиз может полностью сломать старую логику.

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

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

В статье расскажу про задачу и её решение, связанную с организацией лимитов для выполнения различных операций и http запросов. Изначально задача звучала как создание распределенного решения, библиотека или микросервис на основе хранилища в redis, который бы мог обеспечить достаточный уровень отказоустойчивости и наблюдаемости. Функциональные и не функциональные требования были обычными для подобной задачи и казалось, что можно обойтись стандартным готовым решением, но не тут то было.

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

Сегодня разбираемся, почему sync.Map — выглядит аппетитно, но почти всегда оказывается не тем, чем вы ожидали.

Привет, Хабр! Меня зовут Владимир Марунин, я ведущий разработчик в команде Clatch. Сегодня расскажу о новых мапах в Go 1.24: разберем изменения, посмотрим, что было и что стало. О мапах часто спрашивают на собеседованиях, а еще без них нельзя просто так взять и написать программу на Go — так что, надеюсь, тема будет полезной и интересной.

Этот текст — расширенная версия моего доклада с митапа МТС True Tech Go. Если больше нравится слушать, а не читать, можно сразу переходить по ссылке. Поехали!

Wails - это легковесный фреймворк, предназначенный для создания кросс-платформенных GUI приложений рабочего стола на golang и стандартных веб технологиях (Svelte, React, Preact, Vue, Lit, Vanilla JS). Ближайшие аналоги это естественно Electron (JS), Tauri (Rust), хочется добавить Qt (С++), но это уже другой уровень. Сразу скажу, что Wails не идеален, имеет множество ограничений и в целом не подойдёт для чего-то крупного, Tauri к примеру более зрелый проект, больше функций, быстрее развивается, больше и живее сообщество, но это уже на rust, а это не наш стэк.

return fmt.Errorf(«otherMethod %w with val %v», err, val)
}
return nil
}

Проблемы такого подхода:
— **Дублирование названий методов** в сообщениях об ошибках
— **Ручное добавление метаданных** (аргументы, переменные) в каждое место
— **Сложность отслеживания** места возникновения ошибки при нескольких точках выхода
— **Засорение кода** — повторяющийся boilerplate
— **Отсутствие структуры** — все метаданные упакованы в одной строке

Что если объединить мощь структурированного логирования (`slog`) с автоматическим сбором локального стека вызовов. Результат — чистый код и информативные логи.
d

## Решение: структурированные ошибки + автоматический стек

**Было:**
```go
func (*SomeObject) SomeMethod(val any) error {
if err := otherMethod(val); err != nil {
slog.Error(err, «val», val) // дублирование
return fmt.Errorf(«someMethod %w with val %v», err, val)
}
return nil
}

Программисты на Go уже давно и долго жалуются на слишком многословную обработку ошибок. Все мы близко (а иногда и болезненно) знакомы со следующим шаблоном кода:

x, err := call()
if err != nil {
// обработка err}

Проверка if err != nil встречается настолько часто, что может становиться объёмнее остального кода. Обычно это происходит в программах, выполняющих много вызовов API, в которых обработка ошибок рудиментарна и они просто возвращаются. Некоторые программы в итоге выглядят примерно так:

func printSum(a, b string) error {
x, err := strconv.Atoi(a)
if err != nil {
return err
}
y, err := strconv.Atoi(b)
if err != nil {
return err
}
fmt.Println("result:", x + y)
return nil }

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

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

Привет! Я Михаил Абраш — старший Go-разработчик, работаю в команде Evolution AI Factory в Cloud.ru. Недавно мы начали активно внедрять новые сервисы, переходя с Python на Go, и заметили, что нагрузка между репликами распределяется неравномерно. У нас в команде не было единого подхода к тому, как правильно делать балансировку, поэтому решили провести небольшое R&D-исследование. Что из этого вышло, к чему мы в итоге пришли и как работает балансировка gRPC в целом, рассказал в статье. 

С 1 июля 2025 года хранить персональные данные россиян в иностранных сервисах больше нельзя. Назрел вопрос, что же делать, например, с регистрациями на мероприятия, которые так удобно складывались из формочек Tilda напрямую в Google Sheets без СМС и регистрации. В статье расскажу, как я эту задачу решил с помощью бесплатного open-source сервиса Grist, платного, но копеечного Яндекс Облака и сомнительного Go кода.

Продолжаю цикл статей про использование Greenmask - инструмента, который написан на Go специально для безопасной работы с данными PostgreSQL: он помогает делать логические бэкапы, восстанавливать таблицы и при необходимости — анонимизировать чувствительную информацию.

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

Еще раз про gomock и тесты. Практики как можно писать тесты быстро, сохраняя их качество, при этом не лить горючие слезы.

Привет! Я Артур Давыдов, бэкенд разработчик в Здравсити. В этой статье хочу рассмотреть поведение defer более детально. Данную статья пишется в целях "попробовать себя", а так же, надеюсь, помочь кому-то разобраться с defer.

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

Сегодня разберём, как устроен reflect.Value изнутри и что на происходит, когда вы вызываете .Field(i).

Go — язык, который ценится за простоту и чёткость. Однако даже при минимальном синтаксисе здесь есть нюансы. Особенно это касается работы с функциями и методами. В этой статье хочу поделиться личными наблюдениями и выводами по нескольким ключевым темам: выбор типа получателя, использование именованных параметров результата, распространённые ошибки при возврате nil, проблемы с файлами в качестве входных данных и поведение defer.
ps. Обложку нейронка сгенерировала. Очень странно, но мне понравилось.