В Go 1.18 добавлена поддержка дженериков. Это самое большое нововведение с момента первого Open Source выпуска Go. Не будем пытаться охватить все детали, затронем всё важное. Подробное описание со множеством примеров смотрите в документе с предложением по улучшению языка. Материалом делимся к старту курса по Backend-разработке на Go.

Введение

Привет Хабр!

Продолжая тему тестирования на Go, сегодня поговорим про table-driven тестирование.
У нас есть основная проблема: дублированный тестовый код.

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

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

Как в Golang логирование поживает? Рассмотрим этот вопрос в статье.

Рассмотрим основные библиотеки и подходы.

В Go 1.22 ожидается появление интересного предложения - расширение возможностей по поиску шаблонов (pattern-matching) в мультиплексоре, используемом по умолчанию для обслуживания HTTP в пакете net/http.

Существующий мультиплексор (http.ServeMux) обеспечивает рудиментарное сопоставление путей, но не более того. Это привело к появлению целой индустрии сторонних библиотек для реализации более мощных возможностей. Я рассматривал эти возможности в серии статей "REST-серверы на Go", в частях 1 и 2.

Новый мультиплексор в версии 1.22 позволит значительно сократить отставание от пакетов сторонних разработчиков, обеспечив расширенное согласование. В этой небольшой заметке я кратко расскажу о новом мультиплексоре (mux). Я также вернусь к примеру из серии "REST-серверы на Go" и сравню, как новый stdlib mux справляется с gorilla/mux.

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

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

Сегодня мы поговорим о двух концепциях — Event Sourcing и CQRS, и их реализации на языке Go. Go предоставляет хорошие возможности для реализации этих паттернов благодаря своей производительности, простоте и поддержке конкурентности «из коробки».

Привет, Хабровчане!

Для тех, кто не в курсе, gRPC - это открытый фреймворк от Google, который был представлен миру в 2016 году. Основываясь на протоколе HTTP/2, gRPC использует Protocol Buffers в качестве языка описания интерфейса.

Основная идея gRPC заключается в создании универсального механизма для эффективного и быстрого обмена данными между различными сервисами и приложениями. В этом его главное отличие от традиционных REST API. gRPC работает на основе протоколов, которые определяют "контракты" между клиентом и сервером, позволяя им общаться независимо от ЯПа.

В этой статье мы научимся писать полноценный gRPC сервис на Go на примере сервера авторизации с полноценной архитектурой, готовой к продакшену. Мы напишем как серверную часть, так и клиентскую. В качестве клиента мы возьмём мой сервис — URL Shortener, о котором у меня также есть статья и видео-гайд на ютубе. Попутно мы познакомимся с базовыми подходами к работе с авторизацией. И в конце настроим автоматический деплой сервиса с помощью GitHub Actions на удалённый сервер.

Видео-версия этого гайда с более подробными объяснениями

Исходный код проекта: https://github.com/GolangLessons/sso

Итого, наш план:

• Напишем простой, но полноценный gRPC-сервис
• Разберемся с базовыми принципами работы авторизации — чтобы не было скучно
• Настроим автоматический деплой в прод — потому что руками деплоить лень
• Подружим его с уже готовым сервисом URL Shortener — чтобы был практический смысл
• Напишем полноценные функциональные тесты

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

Кратко обо мне: меня зовут Николай Тузов, я много лет занимаюсь разработкой на Go, очень люблю этот язык. Также веду свой YouTube-канал.

Одна из самых важных задач ЯП`s это эффективное взаимодействие с базами данных и Go не исключение. В Go есть парадигма Object-Relational Mapping (ORM), позволяет работать с реляционными базами данных в терминах объектно-ориентированного программирования. Это очень сильно упрощает работу с базами данных, позволяя сосредоточиться на бизнес-логике приложения, а не на нюансах SQL-запросов.

GORM (Go Object-Relational Mapping) предоставляет удобный интерфейс для взаимодействия с различными базами данных, сохраняя при этом идиоматичность и фичу конкуретности в Go.

Изящное завершение работы (Graceful Shutdown) важно для любого длительного процесса, особенно для того, который обрабатывает состояние. Например, что если вы хотите завершить работу базы данных, поддерживающей ваше приложение, а процесс db не сбрасывает текущее состояние на диск, или что если вы хотите завершить работу веб-сервера с тысячами соединений, но не дожидаетесь окончания запросов. Изящное завершение работы не только положительно сказывается на пользовательском опыте, но и облегчает внутренние операции, что приводит к более счастливым инженерам и менее напряженным SRE.

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

"Правильно заданный вопрос - половина ответа". Осваиваю профессию Prompt Engineering. Это ответы на вопросы. Мопед не мой. Спасибо, Codeium. Не обрабатывал наводящие подвопросы, а надо бы. Но может быть кому-то пригодится и в таком виде.

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

Перевод познавательной статьи "Golang: channels implementation" о том, как устроены каналы в Go.

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

Устройство канала

Давайте начнём с разбора структуры канала:

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

Атомики в Go - это один из методов синхронизации горутин. Они находятся в пакете стандартной библиотеки sync/atomic. Некоторые статьи сравнивают atomics с mutex, так как это примитивы синхронизации низкого уровня. Они предоставляют бенчмарки и сравнения по скорости, например Go: How to Reduce Lock Contention with the Atomic Package.

Однако важно понимать, что, хотя это примитивы синхронизации низкого уровня, они разные по своей сути. Прежде всего атомики являются "low-level atomic memory primitives", как отмечено в документации, то есть являются примитивами низкого уровня реализующих атомарные операции с памятью. В этой статье я расскажу про некоторые особенности их внутренней реализации и отличие от мьютексов.

{
	"name":"qwerty",
	"price":258.25,
	"active":true,
	"description":null,
}

type QueryError struct {
    Query string
    Err   error
}

func (e *QueryError) Error() string { return e.Query + ": " + e.Err.Error() }