Golang книги

Недавно на GitHub наткнулся на отличную открытую книгу: The Accidental CTO. Автор не из академической среды, но шаг за шагом развил платформу с нуля до уровня, способного выдержать миллион пользователей. В книге не шаблонные ответы про «лучшие практики», а реальный опыт, осел после падений в ямы, тушения пожаров и разборов полетов: как пережить крах сервера в три часа ночи, как догнать задержку репликации базы данных, как поэтапно наращивать архитектуру. Она через истории раскрывает ключевые концепции распределенных систем, а заодно выкладывает на стол компромиссы за техническими решениями: почему выбрали именно так, какой ценой, как развивать дальше. GitHub: http://github.com/subhashchy/The-Accidental-CTO

⚡️ Вы слышали про Rust. Знаете, что он быстрый, безопасный и что за ним будущее. Осталось одно: сесть и выучить. Этот курс со Stepik- кратчайший путь от «знаю что такое Rust» до «пишу на нём». 6 модулей, 50 уроков, 143 теста. Ownership, borrowing, traits, async, Tokio, Axum, макросы, WASM — всё разложено по полочкам и закреплено практикой. Никакого видео на 40 минут ради одной мысли. Подробный текст, много кода, реальные задачи после каждого урока. На выходе — портфолио из 10+ проектов: от CLI-утилит до REST API с базой данных. 48 часов действует скидка 55 процентов: stepik.org/course/269250

OpenAI-compatible API на Go - что внутри у такого провайдера Интересная статья про то, как устроить OpenAI-compatible provider на Go. Смысл в том, чтобы сделать сервис, который снаружи выглядит как OpenAI API, но внутри может ходить в другой backend, модель или собственную инфраструктуру. Это полезно, когда нужно подключать LLM к уже существующим инструментам без переписывания клиентов. Многие SDK, агенты и inference-пайплайны уже умеют работать с OpenAI-форматом, поэтому совместимый слой становится универсальным адаптером. В статье разбирается практическая анатомия такого провайдера: HTTP API, формат запросов и ответов, streaming, обработка ошибок и то, как аккуратно связать это с Go-кодом. Хороший материал для тех, кто пишет LLM-инфраструктуру, gateways, proxy-сервисы или хочет понять, как строятся совместимые API вокруг моделей. https://blog.anh.sh/anatomy-of-an-openai-compatible-provider-in-go #golang #llm #openai #api #backend

📈 Ещё месяц назад вы могли не знать о Go ничего. Сегодня — читаете этот канал. Следующий уровень — начать применять знания на практике. Чтобы ускорить процесс, попробуйте структурированный подход: обновлённый курс 2025 года «Go-разработчик с нуля» от Нетологии. На нём вы: - Выстроите прочную базу по Golang: от написания первых строк кода до работы с модулями, файлами и ошибками. - Изучите основы DevOps, поймёте, как работать с данными, создавать веб-приложения и REST API. - Попрактикуетесь на реальных задачах и добавите в портфолио 5 масштабных проектов. - Пройдёте тестовые собеседования и получите возможность стажировки. А потом сможете читать этот канал с ещё большим интересом и понимать каждое обсуждение. 👉 Начать учиться со скидкой 45% Реклама. ООО “Нетология” ОГРН 1207700135884 Erid:2VSb5wRYFJS

Ты думаешь, что conn.Read() блокирует? Нет. Тебя красиво обманули В Go ты пишешь максимально прямолинейно: открыл соединение, читаешь данные, ждешь. Выглядит как обычный blocking I/O. Но если бы это было правдой, любой highload сервис умирал бы уже на нескольких тысячах соединений. Под капотом работает netpoller. Это часть runtime, которая превращает твой “блокирующий” код в неблокирующую систему с event loop логикой. Когда goroutine делает conn.Read(), она не блокирует поток. Если данных нет, runtime просто паркует goroutine и освобождает поток для других задач. В этот момент файловый дескриптор уходит в epoll, kqueue или IOCP в зависимости от системы. Как только ОС говорит “данные готовы”, netpoller будит нужную goroutine и возвращает ее в scheduler. Всё. Никаких потоков на каждое соединение, никакого оверхеда на контекст-свитчи. И вот тут главный трюк Go. Ты пишешь код как синхронный. Но исполняется он как асинхронный. Без колбэков, без promise, без ручного управления состоянием. По сути это комбинация scheduler + event loop, спрятанная внутри runtime. Ты не видишь сложность, но получаешь масштабируемость. Именно поэтому тысячи goroutines могут одновременно ждать I/O почти бесплатно. Каждая занимает килобайты памяти, а не мегабайты как поток. Но есть нюанс. Netpoller это не бесконечная магия. При экстремальной нагрузке он сам может стать узким местом. Один poll loop, огромное количество событий и привет, рост latency на хвостах. В итоге Go делает редкий финт. Даёт тебе простой синхронный код и сам превращает его в высоконагруженную асинхронную систему. https://internals-for-interns.com/posts/go-netpoller/

👣 Go slog за 30 секунд: из чего он реально состоит Весь пакет log/slog построен на 5 типах. • Value - контейнер для значения. Число, строка, bool. • Attr - пара ключ-значение. Например name=alice. • Logger - точка входа. Принимает сообщение и атрибуты, собирает событие. • Record - готовое лог-событие: время, уровень, сообщение и набор Attr. • Handler - обрабатывает Record. Форматирует и пишет в io.Writer. Вот и всё. Минимум сущностей, максимум гибкости. Поэтому slog легко расширять и встраивать в любую систему логирования. https://www.youtube.com/shorts/zq50yqfgZGI

🚀 Ты всё ещё называешь обёртку над ChatGPT «AI-продуктом»? Пока ты пишешь промпты - рынок уже ушёл дальше. Сейчас выигрывают не те, кто умеет красиво формулировать запросы, а те, кто строит агентные системы: - принимают решения сами - ходят в API - работают с Postgres и Redis - управляют браузером через Playwright - доводят задачи до результата без человека И вот правда, о которой мало говорят: 90% таких систем умирают между ноутбуком и продом. Работает локально. Ломается в реальности. Нет архитектуры. Нет устойчивости. Нет деплоя. AI Agents Engineering - курс со Stepik, который закрывает этот разрыв. - LangGraph, AutoGen, Computer Use - архитектура агентов, а не «скрипты на коленке» - LLMOps, логирование, стабильность - деплой в Docker и работа в проде 8 модулей, 120+ шагов, всё через практику. На выходе не «сертификат ради галочки», а: - рабочий production-агент - понимание, как строить такие системы с нуля - навыки, за которые уже платят Сейчас самое окно входа. Через полгода это станет базой, а не преимуществом. Скидка 55% действует ещё 48 часов: https://stepik.org/a/276971/

🚀 MCP сервер на Go за пару строк - без JSON-адa Нашли минималистичный фреймворк hamr для сборки MCP серверов на Go. Главная идея - схема генерируется прямо из struct тегов. Пишешь обычную Go-структуру, добавляешь теги — и получаешь готовый JSON schema без ручной возни. Дальше ещё проще: • регистрируешь функцию как tool • одна строчка и она уже доступна через MCP • никакого бойлерплейта По сути убирается самая раздражающая часть - сотни строк JSON-RPC, валидации и обвязки, которые обычно приходится писать руками. В реальном кейсе: MCP сервер с 6 инструментами - ~157 строк без фреймворка — ~480 строк и меньше функционала Интересный момент из-за меньшего объёма кода AI-агенты генерируют такие серверы быстрее и с меньшим количеством ошибок. Если работаешь с MCP и Go- выглядит как один из самых простых способов быстро поднять сервер под агента github.com/AKhilRaghav0/hamr

Для тех, кто строит и масштабирует сервисы на Go: 25 апреля пройдет Я.Субботник по Go Яндекс проведет митап офлайн в Санкт-Петербурге и онлайн. Участников будут ждать практические доклады, живые кейсы и решения, проверенные под нагрузкой. Руководитель группы разработки Городских сервисов Владимир Тельбухов покажет, как наладить консистентность в интеграциях с внешними сервисами. А разработчик Yandex Cloud Иван Похабов, расскажет, как устроен GoBGP, какие баги в нём встречаются и как их исправляют в production. Полную программу выступлений можно найти на сайте. Помимо докладов, для участников проведут круглые столы, квиз по Go, а также экскурсию по питерскому офису Яндекса, для которой офлайн-участникам потребуется предварительная регистрация. 👉 Регистрируемся

🚀 Rust внутри Go без CGO - новый хак, который может всё изменить Наткнулись на разбор, как дергать Rust-библиотеки из Go с отключённым CGO. И это не просто эксперимент, а вполне рабочий подход. Суть в том, что вместо стандартного CGO используется низкоуровневый вызов через runtime и FFI, без компилятора C и всей сопутствующей боли. Почему это вообще важно: CGO ломает главный плюс Go - статические бинарники усложняет сборку и деплой и даёт ощутимый оверхед на вызовы Здесь это обходится. Под капотом используется runtime.asmcgocall - внутренний механизм Go, который позволяет вызывать внешние функции напрямую Что получаем: • чистый Go-бинарник без CGO • проще деплой • возможность использовать Rust как high-performance слой внутри Go Но есть нюансы: планировщик Go не знает, что поток занят GC может ждать окончания вызова и всё это завязано на внутренности runtime, которые могут сломаться в новых версиях Go То есть это уже не «просто интеграция», а почти хак уровня рантайма. Вывод простой если нужен максимум перфа и контроль - Rust + Go без CGO начинает выглядеть очень интересно Но это инструмент для тех, кто готов жить на грани runtime и следить за обновлениями Go stoolap.io/blog/2026/04/08/calling-a-rust-library-from-go-with-cgo-disabled/