💡 Улучшаем отладочный вывод с %+v и %q вместо %v и %s.

При отладке более четкий и детализированный вывод логов может быть очень полезен.

Возьмем типичную ситуацию, когда вы быстро проверяете состояние структуры с помощью fmt.Println:

fmt.Println(GameStats{30, 15, 5})

Вывод:

{30 15 5}

Здесь не сразу понятно, какое число относится к Wins, какое к Losses, а какое к Draws,

...если только вы не помните порядок полей в структуре.

Но, используя %+v и %#v, которые являются вариациями %v, можно сделать вывод более информативным и удобочитаемым:
🔹%+v включает имена полей прямо в вывод, устраняя любую двусмысленность.
🔹%#v идет еще дальше, показывая полную структуру с пакетом и типом. Это может быть избыточным в повседневных сценариях, но полезно в сложных случаях.

"А как насчет %q?"

%q — это, по сути, способ обернуть строки в кавычки, тогда как %s просто выводит строку как есть.

Это различие может быть полезным, особенно при работе с:
🔹Пустыми строками
🔹Строками, содержащими специальные символы или пробелы, которые не сразу заметны

Просто посмотрите на логи, сгенерированные разными форматами, и обратите внимание, насколько понятнее становятся проблемы при использовании %q.

"А есть ли недостатки?"

Стоит учитывать, что %q не интерпретирует управляющие последовательности, такие как \t или \n, что может сделать строку менее читаемой.

(Хотя это может быть полезно, поскольку позволяет увидеть строку в точности такой, какая она есть, сохраняя все специальные символы.)

👉 @juniorGolang | #tip

Управляем множеством горутин с errgroup

Когда у нас много горутин, бывает сложно обрабатывать ошибки и координировать их выполнение.

Ты, наверное, знаком с sync.WaitGroup, да? Но есть пакет errgroup, который упрощает эту задачу.

В примере мы загружаем две страницы и ждем их завершения с g.Wait().

errgroup помогает управлять несколькими горутинами и обрабатывать ошибки, которые они могут вернуть.

Три ключевых момента:
🔹Для параллельного выполнения задач используй g.Go(), передавая в него функцию.
🔹g.Wait() ждет завершения всех горутин и возвращает первую возникшую ошибку (но не все сразу).
🔹errgroup хорошо работает с контекстом.

При использовании errgroup.WithContext() в случае ошибки контекст отменяется.

Как это работает внутри
1. Group использует несколько механизмов:
🔹sync.WaitGroup — чтобы дождаться завершения всех горутин.
🔹sync.Once — чтобы безопасно сохранить первую ошибку.
🔹Семафорный chan — для ограничения числа одновременно работающих горутин (можно задать лимит через errg.SetLimit()).

2. errg.done() — вспомогательная функция, которая помечает горутину завершенной.
🔹Уменьшает счетчик активных горутин (если установлен лимит).
🔹Сообщает WaitGroup, что горутина завершилась.

3. Ошибки обрабатываются централизованно.
🔹С помощью errOnce фиксируется только первая ошибка, которая затем приводит к остановке и возвращается через Wait().

И да, горутины — это не всегда лучшее решение. Если задачи быстрые, последовательное выполнение может быть эффективнее

👉 @juniorGolang | #tip

Трюк для сокрытия методов и предотвращения утверждений интерфейсов в Go.

Например, есть тип A с методом Hello(), который удовлетворяет интерфейсу Greeter.
Если передать экземпляр A в Greet(), интерфейсное утверждение успешно пройдет, и будет вызван Hello().

Но если нужно использовать A, не открывая его метод Hello(), можно скрыть его через встраивание.
При вызове Greet(ANoHello{A: A{}}) интерфейсное утверждение провалится и выведет: "g does not implement Greeter".

Хотя ANoHello встраивает A, содержащий метод Hello(), неэкспортируемое поле noHello имеет приоритет и скрывает его.

Полезно в редких случаях (например, os.File), но стоит знать этот трюк для лучшего понимания встраивания.

👉 @juniorGolang | #tip

Буферизированные каналы как семафоры для ограничения выполнения горутин

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

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

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

В этом примере:

🔹wg.Add(10) — мы подготавливаемся к завершению 10 горутин.
🔹make(chan struct{}, 3) — это создает семафор, позволяющий одновременно работать только 3 горутинам.

Если нужен более аккуратный способ управления этим процессом, можно рассмотреть создание типа Semaphore, который будет обрабатывать все действия, связанные с семафором.

Использование такого пользовательского типа Semaphore упрощает управление доступом к ресурсам в наших функциях.

Также существует реализация семафора в пакете golang.org/x/sync/semaphore, которая представляет собой взвешенный семафор.

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

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

👉 @juniorGolang | #tip