Библиотека Go-разработчика | Golang

🤔 Вопрос с собеседования по Go

Что выведет программа?

❤️ — [1 2 3 4 5] / [1 2 10]
🔥 — [1 2 10 4 5] / [1 2 10]
👍 — [1 2 3 4 5] / [1 2 3]

👇 Правильный ответ (нажми, чтобы прочитать):

🔥 — [1 2 10 4 5] / [1 2 10]

b := a[:2] создаёт слайс, который использует тот же backing array, что и a.

У b остаётся capacity до конца исходного массива, поэтому append не выделяет новый массив, а записывает 10 в третий элемент.

В итоге изменяется и a:

[1 2 10 4 5]
[1 2 10]

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

🛠 Rune — open-source IDE и terminal multiplexer на Go

Rune объединяет IDE, терминал и AI-agent в одном приложении.

Что интересного:

• GPU-ускоренный интерфейс;
• native graphics: OpenGL на Linux и Metal на macOS;
• language intelligence из коробки;
• встроенный agent;
• терминалы, вкладки и окна в едином workspace;
• E2E-зашифрованная сеть между экземплярами Rune.

Без Electron — приложение использует нативный графический pipeline.

Установить:

curl -fsSL https://rune.build/install.sh | sh

🔗 GitHub

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction

🤩 SQLite вместо отдельного брокера в Go

Watermill поддерживает SQLite Pub/Sub — сообщения передаются между publisher и subscriber через таблицы SQLite.

Что это даёт:

— не нужен Kafka, RabbitMQ или Redis;
— сообщения хранятся в SQLite-файле;
— данные переживают перезапуск приложения;
— удобно для небольших сервисов и локальной разработки.

🔴 Публикация:

publisher, err := wmsqlitemodernc.NewPublisher(
    db,
    wmsqlitemodernc.PublisherOptions{
        InitializeSchema: true,
        Logger:           logger,
    },
)

msg := message.NewMessage(
    watermill.NewUUID(),
    []byte(`{"message":"Hello, world!"}`),
)

err = publisher.Publish("messages", msg)

Подключается как обычный Pub/Sub Watermill — при этом отдельный брокер не требуется.

⚠️ SQLite Pub/Sub всё ещё Beta: реализация стабильна, но недостаточно проверена в production. Для высоких нагрузок учитывайте ограничения SQLite.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

⚡️ Go 1.27 ускоряет небольшие аллокации

В Go 1.27 появился size-specialized memory allocation — специальные пути выделения памяти для небольших объектов.

Что изменилось:

— аллокации объектов размером менее 80 байт могут стать быстрее на 20–30%;
— в программах с большим количеством аллокаций общий прирост может достигать 1%;
— максимальный эффект ожидается для объектов на 16 и 24 байта.

🔴 Почему это работает?

Раньше runtime использовал общий путь mallocgc, которому нужно определить размер объекта, класс аллокации и дополнительные параметры.

➡️ Теперь для часто встречающихся размеров есть специализированные функции. Они заранее знают размер объекта и могут:

— быстрее очищать память;
— не вычислять класс аллокации повторно;
— эффективнее выполнять служебные операции;
— использовать более короткий fast path.

Особенно часто такие размеры встречаются у структур, интерфейсов, строк и слайсов.

🔗 Ничего менять в коде не нужно. Чтобы получить улучшения, достаточно пересобрать приложение с Go 1.27.

При необходимости эксперимент можно отключить:

GOEXPERIMENT=nosizespecializedmalloc

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoLive

🛠 Напишите конфиг сами

viper — самая частая рекомендация для конфигурации в Go. Он умеет читать файлы, переменные окружения, удалённые источники и устанавливать дефолты. Звучит удобно, но на практике создаёт проблемы.

🔴 В чём проблема

Viper тянет большое дерево зависимостей. Методы GetString, GetInt и подобные не типизированы — значения возвращаются в рантайме без проверки на этапе компиляции. Ключи конфига разбросаны по коду как строковые литералы. При нетривиальном использовании поведение при слиянии и приоритетах конфигов требует чтения исходников.

🔴 Что использовать

Структура с тегами и yaml.NewDecoder:

type Config struct {
    DatabaseURL string      `yaml:"database_url"`
    Kafka       KafkaConfig `yaml:"kafka"`
    Server      ServerConfig `yaml:"server"`
}

func Load(path string) (*Config, error) {
    f, err := os.Open(path)
    if err != nil {
        return nil, err
    }
    defer f.Close()

    var cfg Config
    if err := yaml.NewDecoder(f).Decode(&cfg); err != nil {
        return nil, err
    }
    return &cfg, nil
}

Переменные окружения добавляются вручную через os.Getenv там, где это нужно.

🔴 Что получаем

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

Для JSON-конфига подход тот же, только с encoding/json. Пакет gopkg.in/yaml.v3 — единственная внешняя зависимость, и та минимальная.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction

🔥 Шейдеры на Go: как оживить игру с помощью кода

В Ebitengine шейдеры пишутся на Kage — языке с Go-подобным синтаксисом. С их помощью можно создавать эффекты прямо на уровне пикселей:

— маска повреждений зданий;
— «дрожащий» рукописный текст;
— ретро-CRT и глитчи;
— зацикленная анимация текстур;
— эффект строительства зданий.

➡️ В статье — практические примеры из игр Roboden и Decipherism, а также разбор Fragment(), текстур, uniform-параметров и DrawRectShader().

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction

😭 Как не потратить недельный лимит AI-кодинга за три дня?

Разберём на вебинаре, как тратить меньше на AI-агентов — без потери качества кода.

🔘 Поговорим о том:

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

✏️ Покажем всё на конкретных цифрах и вживую: сравним расходы до и после.

⬇️ 17 сентября, 19:00 МСК
⬇️ 1,5 часа · бесплатно
⬇️ Арсений Харланов и Олег Лайок

💬 Пишите в комментариях, где упираетесь в лимиты и на что уходят деньги. Самые залайканные вопросы разберём на вебинаре.

🔗 Зарегистрироваться на вебинар⁠

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

🤔 Вопрос с собеседования по Go

Что выведет программа?

❤️ — числа выведутся по порядку
🔥 — числа выведутся в случайном порядке
👍 — программа завершится с ошибкой

👇 Правильный ответ (нажми, чтобы прочитать):

🔥 — числа выведутся в случайном порядке

Каждая итерация запускает отдельную горутину. Значение val передаётся в функцию аргументом v, поэтому все горутины получают правильное число.

Но порядок выполнения горутин не гарантирован планировщиком Go. Поэтому вывод может быть, например:

30
10
50
20
40

sync.WaitGroup нужен, чтобы дождаться завершения всех горутин.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

Вы вообще видели, что сделала команда AvitoTech ко Дню разработчика?!

В честь наступающего праздника вместе со студией FU2RE и 3D-художником Dmitriev Video ребята создали большой портал в прошлое — эмулятор 2006 года будущего разработчика. Внутри — олдскульные игры и викторины, за которые можно лутать баллы и подниматься в рейтинге.

Топ-3 игроков 15 сентября получат суперпак настоящих разрабов, внутри которого салфетка на монитор из коллаборации с Elnik, плед, сумка и плюшевый талисман — кот Б/У. Так что времени сыграть ещё много!

P. S. Сыграть в эмулятор и побороться за призы можно до 15 сентября. Так что успевайте ❤

🌸 Вселенная намекает: пора уже начать этот курс

С 14 сентября цены в Proglib Academy вырастут на 20% 👀

Так что если курс давно ждёт своего часа — лучше не откладывать ещё на месяц 😏

📍 Выбрать курс

👎 Почему context.Value портит код

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

Но именно в этом и проблема context.Value превращается в чёрный ящик, ломает типобезопасность и делает важные зависимости невидимыми.

Паттерн «A положил payment в контекст, C его вытащил, а B просто прокинул ctx дальше» выглядит аккуратно, пока вы помните все неочевидные места чтения. Через неделю уже не видно, какие функции реально зависят от payment а это критические бизнес данные, спрятанные в контейнер без гарантий на уровне компилятора.

Любая ошибка в ключе, типе или месте, где забыли вызвать WithValue, всплывает только в рантайме, иногда в виде тихих багов, а не паники.

Как обычно делают с context.Value:

type Payment struct {
    ID     string
    Amount int
}

func A(ctx context.Context, transactionID string) {
    payment := dbGetPayment(ctx, transactionID)

    // Кладём бизнес данные в контекст
    ctx = context.WithValue(ctx, "payment", payment)

    B(ctx)
}

func B(ctx context.Context) {
    // Эта функция формально не знает про payment,
    // но обязана протащить ctx дальше
    doSomething(ctx)
    C(ctx)
}

func C(ctx context.Context) {
    // Где то глубоко в стеке достаем payment из «чёрного ящика»
    payment, ok := ctx.Value("payment").(Payment)
    if !ok {
        log.Println("payment not found in context")
        return
    }

    processPayment(payment)
}

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

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoDeep

С днем программиста, коллеги!

Желаем, чтобы код компилировался с первого раза, баги находились до релиза, а таски «на пять минут» действительно занимали пять минут. 

И конечно, пусть в жизни будет больше приятных сюрпризов — один из них мы уже подготовили. Скорее переходите по ссылке, трясите коробку и забирайте свой подарок ко Дню программиста: https://tprg.ru/I45e

💡 Тестирование ввода из stdin

Тестирование функций, которые читают данные с консоли через fmt.Scan и stdin в Go, часто становится настоящей задачей. В таких случаях нельзя просто передать параметры функции — код напрямую взаимодействует со стандартным вводом.

Пример проблемы:

func ReadName() string {
    var name string
    fmt.Print("Enter your name: ")
    fmt.Scan(&name)
    return name
}

Для этой функции сложно написать unit-тест, потому что она читает из os.Stdin, а в тестах обычно хочется подставлять свои данные.

Решение: подменяем os.Stdin

В тестах можно временно переназначить os.Stdin на чтение из заранее подготовленного буфера:

func TestReadName(t *testing.T) {
    input := "Alice\n"
    r, w, _ := os.Pipe()
    w.WriteString(input)
    w.Close()
    oldStdin := os.Stdin
    defer func() { os.Stdin = oldStdin }()
    os.Stdin = r

    got := ReadName()
    want := "Alice"
    if got != want {
        t.Errorf("got %q, want %q", got, want)
    }
}

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

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

🌞 Готовим вебинар про AI в разработке и хотим сделать его максимально полезным

Что реально хочется разобрать? Где чаще всего застреваете? Что пробовали, но так и не получилось нормально внедрить?

🤩 Пишите вопросы в комментариях — самые залайканные разберём на вебинаре в первую очередь.

Задавайте всё, что давно хотелось спросить 📍

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

👩‍💻 15 вопросов по PostgreSQL, которые стоит знать Go-разработчику

Если идёте на Middle Go, одного синтаксиса SQL мало. На собеседовании легко уйти в индексы, транзакции и конкурентный доступ.

Сохраняйте чек-лист:

B-tree — когда используется и какие запросы ускоряет?
EXPLAIN ANALYZE — что показывает и чем отличается от EXPLAIN?
Почему PostgreSQL выбирает Seq Scan, хотя есть индекс?
Составной индекс — что это и зачем нужен?
Левый префикс — почему порядок колонок в индексе важен?
Как выбрать порядок колонок в составном индексе?
MVCC — как PostgreSQL позволяет транзакциям работать параллельно?
Уровни изоляции — какие бывают и чем отличаются?
Deadlock — как возникает и как его предотвращать?
SELECT ... FOR UPDATE — когда нужен?
N+1 — откуда появляется и как его найти?
ACID — что означает каждая буква на практике?
Connection pool — зачем он нужен и какие проблемы возникают при неправильных настройках?
Replication lag — почему реплика отстаёт и чем это опасно?
Partitioning vs Sharding — в чём разница и когда применять каждый подход?

🔥 Если можете не просто дать определение, а привести пример из реального сервиса на Go, скорее всего, с базовыми вопросами PostgreSQL на собеседовании проблем не будет.

С вас 🔥, если полезно!

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

🔄 Можно ли в Kafka перечитать сообщения?

Да. Пока сообщение не удалено по retention, consumer может вернуться к старому offset и обработать его снова.

🔴 Это особенно полезно, если в обработчике обнаружили баг:

исправили код → сдвинули offset назад → переиграли сообщения

Например, для consumer group можно сбросить offset через kafka-consumer-groups.

💡 Важно: offset хранится для consumer group, поэтому сброс влияет на чтение этой группой.

Kafka в этом плане отличается от классической очереди: прочитанное сообщение не исчезает сразу — его можно переиграть.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

🤔 Вопрос с собеседования

Что произойдёт, если одна горутина надолго зациклится на CPU и не будет делать ни sleep, ни syscall, ни операций с каналами?

❤️ — вторая горутина не выполнится, потому что P всего один
🔥 — планировщик вытеснит первую горутину и запустит вторую
👍 — вторая выполнится только после runtime.Gosched()

👇 Правильный ответ (нажми, чтобы прочитать):

🔥 Начиная с Go 1.14 планировщик поддерживает асинхронное вытеснение. Поэтому даже CPU-bound горутина, которая не блокируется и не вызывает runtime-функции, не может бесконечно удерживать P.

GOMAXPROCS(1) означает, что одновременно выполняется только одна горутина, но планировщик может переключать между несколькими G.

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

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

🔗 Как Go запускает горутины

В Go тысячи горутин не привязаны напрямую к потокам ОС. Runtime распределяет их через GMP-модель:

⬇️G (Goroutine) — что
⬇️нужно выполнить;
⬇️M (Machine) — поток ОС,
⬇️на котором выполняется
⬇️код;
⬇️P (Processor) — ресурс
⬇️планировщика, который
⬇️связывает G и M.

У каждого P есть своя локальная очередь горутин. Если работы не хватает, планировщик может взять её из глобальной очереди или украсть часть очереди другого P — это work-stealing.

🟡 А если M блокируется на syscall, P не обязан ждать его возвращения: runtime может передать P другому потоку через handoff.

🟡 Отдельно за состоянием runtime следит sysmon, а сетевые операции обслуживает netpoller, поэтому ожидание I/O обычно не означает простой потока ОС. Именно эта связка позволяет Go одновременно держать много горутин и эффективно использовать несколько CPU.

А вся схема — на картинке 🤩

🔗 Читать подробнее про планировщика

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoDeep

💡 Почему Go нельзя просто установить и забыть

С Go часто делают так: выбрали версию, прописали её в Dockerfile — и вспоминаем о ней только при следующем большом обновлении. Но security-патчи выходят внутри той же ветки. И если ваша версия старая, опубликованная уязвимость превращает её в известную цель.

📍 Поэтому версия Go в проде должна обновляться примерно так же, как обычные зависимости.

Что стоит сделать:

— закрепить конкретный toolchain в go.mod;
— регулярно пересобирать Docker-образ;
— следить за security-анонсами Go;
— проверять зависимости через govulncheck.

Например:

toolchain go1.26.6

А CI может брать версию прямо из go.mod:

- uses: actions/setup-go@v5
  with:
    go-version-file: go.mod

🔗 Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction