👣 Не самое заметное в Go 1.26, но важное изменение языка - рекурсивные ограничения типов в дженериках.

Раньше ограничения типов не могли напрямую или косвенно ссылаться на параметр типа.

Например, такое объявление интерфейса:

type Ordered[T Ordered[T]] interface {
    Less(T) bool
}

Что приводило к ошибке компиляции: invalid recursive type: Ordered refers to itself.

Начиная с Go 1.26, этот код компилируется без проблем.

Типичный сценарий использования - обобщённый тип, который поддерживает операции с аргументами или результатами того же типа, что и он сам (например, Ordered[T]).

Такой тип можно использовать как элемент обобщённого контейнера, например Tree[T Ordered[T]].

В результате дженерики в Go стали немного более выразительными и гибкими, особенно для структур данных и алгоритмов.

@Golang_google

👣 gitk-go - это реализация классического gitk, но написанная на Go.

Проект нацелен на более современный, быстрый и поддерживаемый просмотр истории Git-репозиториев.

Что это такое
- GUI-инструмент для просмотра истории Git
- альтернатива оригинальному gitk на Tcl/Tk
- написан на чистом Go
- кроссплатформенный

Что умеет
- визуализация коммитов и веток
- просмотр diff-ов
- навигация по истории репозитория
- работа с большими репозиториями

Почему это интересно
Оригинальный gitk:
- старый стек
- медленный на больших репозиториях
- сложен в доработке

gitk-go решает эти проблемы:
- быстрее рендеринг
- современный язык и экосистема
- проще в поддержке и развитии
- хороший пример desktop-приложения на Go

Кому полезно
- тем, кто часто анализирует историю Git
- Go-разработчикам как реальный пример GUI-приложения
- тем, кто хочет легкий и простой Git viewer без IDE

github.com/thiagokokada/gitk-go

#golang #go

👣 Go Concurrency Exercises

Если ты думаешь, что “я знаю Go concurrency”, потому что запускал go func(){} - вот тебе реальный чек.

go-concurrency-exercises - это набор задач, которые заставляют врубиться в конкурентность :
не по книжке, а через боль, race conditions и дедлоки 😅

Что внутри:
✅ задачи на goroutines / channels / select
✅ fan-in / fan-out, worker pool, pipeline
✅ rate limiting, timeouts, context cancel
✅ типичные ловушки: race, deadlock, leak горутин
✅ решения и объяснения - можно сверяться

Подойдет:
- для подготовки к собесам
- для мидлов, которые хотят стать сеньорами
- для тех, кто хочет писать конкурентный Go и разбираться в нем

📎 GitHub: github.com/loong/go-concurrency-exercises

@Golang_google

👻 gh-ost - инструмент для миграций схемы MySQL без даунтайма.

Если тебе надо сделать ALTER TABLE на большой продовой таблице и не положить сервис - gh-ost это прям must-have.

Большинство online-schema-change тулов используют триггеры и создают лишнюю нагрузку.
А gh-ost идёт по другому пути:

✅ Triggerless - вообще без триггеров
✅ Читает изменения через binlog stream и асинхронно применяет их к “ghost table”
✅ Даёт полный контроль над процессом миграции:
- пауза/резюм
- throttle (снижение нагрузки)
- аудит и статус
- безопасный cut-over

Как это работает (по-простому):
1) создаётся “ghost table” с новой схемой
2) данные копируются постепенно
3) параллельно изменения ловятся из binlog
4) в конце таблицы меняются местами почти мгновенно

Идеально для:
🔥 таблиц на десятки миллионов строк
🔥 production-систем
🔥 миграций без блокировок

📌 Репо: github.com/github/gh-ost

👣 Go Developer Survey 2025 - главные выводы

Команда Go опубликовала результаты Go Developer Survey 2025 (опрос проходил в сентябре 2025, ответили 5 379 разработчиков).

Главная мысль отчёта: Go продолжает ощущаться практичным языком для продакшена, а ключевые запросы сообщества - это не «модные фичи», а стабильность, удобство разработки и улучшение опыта работы.

Топ-3 вывода (по версии Go Team):
1) Go нравится разработчикам и хорошо подходит для продакшена
Язык выбирают за простоту, предсказуемость и удобство поддержки.

2) Болевые точки остаются примерно теми же
Больше всего обсуждают:
- обработку ошибок
- `nil`/nil-паники
- отсутствие “нормальных” sum types / более выразительных типов

3) AI-инструменты в Go уже используют, но отношение к ним сдержанное
Видно рост использования AI-помощников, но доверие и «любовь» заметно ниже, чем к классическим инструментам разработки.
Идея простая: пробуют многие, но относятся осторожно.

Почему это важно:
- Go остаётся языком «для работы», а не экспериментов
- комьюнити больше ценит улучшения tooling/экосистемы, чем радикальные изменения языка
- AI-помощники становятся стандартом, но пока не воспринимаются как полностью надёжная замена голове

📌 Полный опрос: go.dev/blog/survey2025
📌 Видео: https://www.youtube.com/watch?v=nMmLMo4lmgA

@Golang_google

👣 Понимание выравнивания памяти в Go

В Go важно понимать, как компилятор размещает данные в памяти - это напрямую влияет на скорость работы и объём используемой памяти.

Что такое выравнивание?

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

Например:
- int64 требует выравнивания по 8 байтам
- int32 - по 4 байтам
- byte - по 1 байту

Если значение лежит “неудобно”, CPU делает несколько операций вместо одной - это медленнее.

Почему появляется padding

Компилятор Go автоматически вставляет пустые байты (padding) между полями структуры, чтобы соблюсти правила выравнивания.

Размер структуры - это не просто сумма размеров полей.

Пример:

type Example struct {
    a byte   // 1 байт
    b int64  // 8 байт (нужно выравнивание по 8)
    c byte   // 1 байт
}

Хотя “полезных” данных тут 10 байт, структура занимает больше из-за вставленного паддинга.

Почему это важно

Если структура используется миллионы раз (в кэше, массивах, базах, сетевых пакетах), лишние байты превращаются в:

• большее потребление памяти
• худшее попадание в CPU cache
• падение производительности

Как оптимизировать

• Порядок полей имеет значение.
• Крупные типы лучше ставить первыми:

type Optimized struct {
    b int64
    a byte
    c byte
}

Так компилятору нужно меньше padding, и структура становится компактнее.

Главное правило

В Go порядок полей в структуре влияет на производительность.

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

Сохрани себе - пригодится при проектировании структур данных.

▪ Больше примеров
▪ Видео