🧑‍💻 Почему конкурентность ≠ параллелизм

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

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

Параллелизм — это реальное выполнение нескольких задач одновременно, используя несколько процессорных ядер.

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

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

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

В некотором смысле, конкуренция — это управление временем, а параллелизм — это управление ресурсами.

Несмотря на различия, конкуренция и параллелизм часто работают вместе.

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

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

#буст

💡 Unit-лид и Technical Owner в команде

Традиционная модель управления «тимлид + продакт-менеджер» показывает ограничения в современных реалиях:
• Масштаб разработки — команды растут до 50-100+ человек
• Сложность продуктов — многокомпонентные системы с десятками интеграций
• Скорость изменений — релизы каждые 2-4 недели вместо квартальных обновлений.

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

➡️ Про эти роли в статье

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

🧑‍💻 Как должна расти зарплата разработчика

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

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

💬 Как вы думаете, насколько быстро должна расти зарплата разработчика? И когда рост должен закончится?

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

#междусобойчик

📰 Дайджест недели

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

— Как находить баги, просто читая код

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

— tRPC-Agent-Go

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

— Как создать многопользовательскую игру с Pion и WebRTC

WebRTC DataChannels вместе с Go и Ebitengine этот подход позволяет быстро и эффективно строить игры, которые могут работать на разных платформах и устройствах.

— Чествование самых глупых решений в области ИИ

AI Darwin Awards — это награды, которые отмечают самые глупые и неосторожные применения технологий искусственного интеллекта, приведшие к катастрофическим последствиям. В 2025 году номинированы самые эпичные провалы.

— 5 трендов IT-найма 2025

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

📌 Шпаргалка по API-дизайну

API — это “дверь” в ваш продукт. Через него общаются сервисы, приложения и даже бизнес-процессы.
Если дверь кривая и скрипит — пользователи не захотят ею пользоваться.

Составили для вас шпаргалку по апи.

1. Ясные имена

• Используйте простые и логичные названия.
• Коллекции — во множественном числе: /users, /orders.

2. Идемпотентность

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

3. Пагинация

Нельзя выдавать тысячи строк ответа одним куском: это тормозит работу и перегружает сеть. Вместо этого нужно разбивать результаты на страницы. Существуют разные стратегии: от простого смещения до курсорной модели.

4. Сортировка и фильтры

Управляйте выборкой через query-параметры:
• Фильтр: /users?status=active
• Сортировка: /users?sort=created_at&order=desc

5. Связи ресурсов

В реальном мире данные редко живут изолированно: пользователи связаны с заказами, товары с категориями и так далее. Поэтому лучше строить маршруты вроде /users/{id}/orders, которые сразу показывают, какие данные связаны между собой.

6. Ограничение запросов

Ограничение вроде «100 запросов в минуту» помогает сохранить стабильность для всех пользователей. Обычно сервер сообщает об этом через заголовки ответа: X-RateLimit-Limit, X-RateLimit-Remaining.

7. Версионирование

API неизбежно меняется: появляются новые поля, меняется структура, иногда от чего-то приходится отказываться. Чтобы не ломать существующих клиентов, используется версионирование: кто-то работает с /api/v1/users, кто-то уже перешёл на /api/v2/users.

Хороший апи — это не только про код.

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

#буст

🔄 Go Task: новые улучшения для автоматизации задач

Обновление Go Task v3.45.3 привносит долгожданную поддержку встроенных утилит Windows: cp, mv, mkdir и других команд.

Помимо этого:

• Поддержка глобальных конфигов в $XDG_CONFIG_HOME/task/taskrc.yml или $HOME/.taskrc.yml с расширенной схемой ключей и значений.

• Новые свойства: insecure, verbose, concurrency, remote offline/timeout/expiry.

• Поддержка вложенных и wildcard-задач при выводе через --list --json.

• Исправление паники при пустых хэш-переменных.

➡️ Репозиторий либы

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

#свежак

🎧 Свежий Cup o' Go

После двух недель без выпусков Go авторы подкаста снова радуют сообществo. А в сообществе активность не утихает: доступны видео с GopherCon Europe в Берлине, Damien Neil делится лайфхаками по тестированию асинхронного кода, а новая версия gofumpt показывает, как безопасно работать с “голыми” возвратами функций.

➡️ Слушать подкаст

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

#свежак

🔒 Оптимистическая vs пессимистическая блокировка

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

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

Решение — блокировки в базе данных.

Но какую выбрать: оптимистическую или пессимистическую? От этого решения зависит, будет ли ваше приложение летать или тормозить, масштабироваться или падать под нагрузкой.

➡️ Подробнее про блокировки

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

⚙️ Как из микросервисов сделать монолит

Мы привыкли слышать: «Надо уходить в микросервисы». Но что если это не панацея или стало только хуже? Разберёмся как вернуться к монолиту.

Как это сделать на практике

1. Разобраться в текущей архитектуре

Карта сервисов, API, базы, зависимости. Определяем, что реально стоит объединять.

2. Слить код в один проект

Из множества репозиториев → единый монолит.
Каждый сервис становится модулем внутри одного приложения.

3. Убрать сетевые вызовы

HTTP/gRPC заменяем на обычные вызовы методов.
Больше никаких прокси, discovery и mesh.

4. Централизовать работу с данными

Объединяем схемы в одну БД или хотя бы в одно хранилище.
Транзакции снова становятся простыми и атомарными.

5. Упростить инфраструктуру

Один артефакт, один деплой, один пайплайн.
API Gateway и прочие прослойки уходят в прошлое.

Монолитизация — не шаг назад, а инструмент. Иногда именно он позволяет бизнесу двигаться быстрее.

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

#буст

📎 Понятно, что ничего не понятно

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

Сегодня делимся с вами промптом для анализа логов:

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

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

#буст

🧑‍💻 Программист не кодит

Когда вы шли в разработку, наверняка думали: «буду писать код целыми днями». Но реальность другая — у многих бекендеров до 90 % времени уходит не на код.

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

Получается, мы больше оркестрируем процессы, чем пишем фичи. И это не обязательно плохо: именно эти «не-кодовые» задачи держат систему живой и рабочей.

Но есть обратная сторона: многие начинают чувствовать себя не разработчиками, а менеджерами тасков.

💬 А у вас как? Чувствуете, что реально кодите меньше, чем ожидали, или находите баланс между кодом и всей этой скучной работой?

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

#GoTalk

🔄 Как работает Round Robin

Round Robin — простой и популярный способ распределения ресурсов. Его суть: все задачи выполняются по очереди и получают одинаковый квант времени.

Как это работает:

1. Задача получает фиксированное время (например, 50 мс).
2. Если она успевает завершиться — удаляется из очереди.
3. Если нет — ставится в конец, и очередь продолжается.

По сути, это как дейлик: каждый участник получает ровно минуту, потом слово передаётся следующему.

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

#GoVisual

💡 Структуры в Go: больше, чем просто поля

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

— почему структура весит больше, чем сумма её полей?
— почему один struct можно сравнивать и использовать как ключ в map, а другой — нет?

Ниже заглянем под капот и разберёмся с этим.

➡️ Память, выравнивание и паддинг

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

type A struct {
    B bool   // 1 byte (+7 padding)
    I int64  // 8 bytes
} // Sizeof(A) = 16

type B struct {
    I int64  // 8 bytes
    B bool   // 1 byte (+7 padding for struct alignment)
} // Sizeof(B) = 16 (в данном примере одинаково, но порядок важен при большем числе полей)

В итоге структура весит не 9, а 16 байт. Если перепутать порядок полей в большой структуре — потратите кучу памяти впустую. Иногда простая перестановка int64 выше bool экономит пространство на диске.

➡️ Сравнимость и ключи мапы

В Go структуры можно сравнивать оператором == и использовать как ключи в map. Но есть важное условие: все поля должны быть сравнимыми.

type KeyGood struct {
    ID   int
    Name string
} // можно сравнивать и использовать как ключ

type KeyBad struct {
    Data []byte
} // compile error: []byte несравнимый

Обходные пути:

• Фиксированный массив вместо среза:

type KeyArr struct {
    Digest [16]byte
}

• Строка как ключ (создаёт копию, но работает):

key := string(digestBytes)
m := map[string]string{key: "value"}

• Собственный тип с хэшированием — можно хранить хэш массива байт в uint64 или в строке, и использовать как ключ.

Зная нюансы, вы пишете не просто рабочий код, а код, который работает эффективно и предсказуемо.

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

#GoDeep