Golang Books

⚛️ Читаете канал про Go и ловите себя на мысли: «Что вообще происходит?» Это нормально: без базы даже полезные материалы кажутся сложными. Хорошая новость: за 4 месяца можно выйти на уровень, когда все эти обсуждения станут понятными — и даже полезными для работы. На курсе «Go-разработчик с нуля» от Нетологии вы: - Освоите Golang на продвинутом уровне, даже если никогда не писали код: научитесь писать и запускать программы, использовать Go-модули. - Изучите основы DevOps, поймёте, как работать с данными, создавать веб-приложения и REST API. - Пройдёте тестовые собеседования и получите возможность стажировки у партнёров курса. Сейчас на курс действует скидка 55%, а с промокодом IT10JULY цена станет ещё на 10% ниже. Реклама. ООО “Нетология” ОГРН 1207700135884 Erid:2VSb5zE4fbG

Большой бесплатный курс по Go в формате одной статьи. Learn Go: The complete course от Karan Pratap Singh — это не короткий туториал на 15 минут, а огромный разбор примерно на 159 минут чтения: от установки и Hello World до модулей, интерфейсов, тестов, generics, goroutines, channels, sync, context и concurrency patterns. По сути, это нормальная дорожная карта для тех, кто хочет зайти в Go без хаоса: * синтаксис и типы * функции, структуры, методы * массивы, slices, maps * interfaces и errors * testing и fuzzing * generics * goroutines, channels, mutex, waitgroups * context и продвинутые concurrency patterns Хороший материал, чтобы не просто «выучить синтаксис», а понять, почему Go так часто выбирают для backend, distributed systems, cloud-инфраструктуры и tooling. https://www.karanpratapsingh.com/blog/learn-go-the-complete-course

У gopls появился экспериментальный встроенный MCP-сервер. Теперь Go-инструменты можно подключать к AI-ассистентам не костылями, а через официальный language server: навигация по коду, контекст проекта и часть возможностей gopls становятся доступными как MCP tools. Есть два режима: attached — MCP работает рядом с активной LSP-сессией и видит даже несохранённые изменения в буфере. detached — запускается отдельный gopls mcp и работает только с файлами на диске. Подключение к Claude Code выглядит так: claude mcp add gopls -- gopls mcp Для Gemini CLI тоже есть готовая конфигурация. Главное — поставить gopls v0.20+: go install golang.org/x/tools/gopls@latest Ассистент теперь может понимать Go-проект ближе к тому, как его понимает редактор. https://go.dev/gopls/features/mcp @Golang_google

✔️ LLM-защита до запроса к модели Tamga - open-source reverse proxy на Go, который ставится между приложением и LLM-провайдерами вроде OpenAI, Anthropic и Azure. Задача простая: каждый промпт проходит проверку до отправки в модель. Что умеет: * искать PII, секреты и запрещённые паттерны * редактировать или блокировать опасные запросы * работать как OpenAI-compatible proxy * вести аудит инцидентов * прогонять adversarial-тесты в CI * держать низкую задержку на обычном CPU Самое интересное в статье - честность автора. Он собрал 62 adversarial-вектора и признаёт: 29 из них всё ещё обходят сканеры. Проблемные зоны ожидаемые: * Unicode-трюки * zero-width символы * base64-обёртки * многоязычные prompt injection * перефразированные атаки Вывод для продакшена жёсткий: LLM security нельзя строить только на regex и красивом middleware. Нужны: * нормализация текста до сканирования * быстрый deterministic слой * отдельный semantic judge для сложных случаев * adversarial corpus как часть CI * честный baseline по bypass rate Хороший пример того, как должна выглядеть LLM-инфраструктура в regulated-среде: не «поставили guardrails и забыли», а постоянная проверка, измерение и улучшение. GitHub: https://github.com/yatuk/tamga

Goroutine leak в Go из-за обычного `range` по channel Классическая ошибка: горутина читает канал через for range, но сам канал никто не закрывает. Все значения уже отправлены, producer-горутины завершились, а collector продолжает ждать следующий receive. Итог - каждый tick оставляет зависшую горутину. Буферизация тут не спасает: range по channel заканчивается только после close. Правильный паттерн: producer’ы завершаются, WaitGroup ждёт их, затем отдельная горутина закрывает канал, а consumer спокойно дочитывает результаты и выходит. Мелкая деталь, которая легко превращается в prod leak. https://rednafi.com/go/channel-iteration-goroutine-leak/

👣 M:N concurrency - это одна из причин, почему Go, Tokio, Erlang и Java Loom могут держать огромную конкурентность без миллиона тяжёлых OS-thread. Идея простая: M лёгких задач в user-space работают поверх N настоящих kernel threads Не один поток на всё, как в старых green threads. И не один OS-thread на каждую задачу, как в классической 1:1 модели. Runtime сам решает, какую goroutine, task или virtual thread запустить на доступном системном потоке. Пока одна задача ждёт I/O, scheduler паркует её и отдаёт поток другой задаче. В этом вся магия: • дешёвые задачи • меньше переключений через ядро • масштабирование до огромного числа соединений • work stealing • event loop • runtime scheduler вместо хаоса из тысяч потоков M:N — это не синтаксис async/await и не «фича Go». Это фундаментальная модель, на которой строится современная высоконагруженная конкурентность. https://0xkiire.com/mn-concurrency-model/

В Оксфордском университете написали эссе, объясняющее, как работает «Бесконечность» Годзё Сатору. В эссе “Mathematics Behind Jujutsu Kaisen: Gojo Satoru’s Infinity” разбирают технику Infinity как настоящий математический объект. На поверхности всё похоже на парадокс Зенона: между атакующим и Годжо всегда остаётся расстояние. Его можно делить пополам бесконечно: половина, четверть, одна восьмая и так дальше. Кажется, что атакующий никогда не дойдёт до цели. Но обычная математика быстро ломает эту “абсолютную защиту”. Геометрическая прогрессия сходится: 1/2 + 1/4 + 1/8 + ... = 1 То есть бесконечно много шагов могут дать конечное расстояние и конечное время. С этой точки зрения Infinity не должна останавливать атаку вообще. Дальше начинается интереснее. Через меру Лебега автор показывает, что бесконечный набор точек деления может иметь нулевую длину. То есть “барьер” из бесконечного числа точек не занимает пространства как настоящая стена. Тогда почему атака всё-таки тормозит? Ответ даёт риманова геометрия. Infinity можно понимать не как стену, а как искажение самой метрики пространства рядом с Годжо. Чем ближе атакующий подходит, тем сильнее растягивается “линейка”, которой измеряется расстояние. Физически шаг может быть маленьким, но внутри такой геометрии он ощущается всё длиннее и длиннее. Поэтому техника работает не как невидимая преграда, а как изменение правил измерения пространства. И отсюда становится понятнее, почему Sukuna смог её обойти. Он не “пробил” Infinity обычной атакой. Он атаковал не Годжо как точку внутри пространства, а само пространство, в котором держалась техника. В терминах статьи, World Cutting Slash разрывает непрерывность метрики. Барьер не преодолевается, а теряет основу, на которой существовал. Получается красивый разбор: Infinity Годжо можно описать через сходимость рядов, меру Лебега, риманову геометрию и топологию. Редкий случай, когда аниме-способность реально тянет на мини-курс по современной математике. PDF: https://tomrocksmaths.com/wp-content/uploads/2026/06/achmad-roykhan-sabiq_essay_competition_2026-achmad-roykhan-sabiq.pdf

⚡️ Linux Roadmap: подробный практический курс от нуля до уверенного администратора Это пошаговый маршрут изучения Linux с упором на практику. Каждый раздел содержит объяснение «почему это устроено именно так», разбор команд и обязательные задания, которые нужно выполнить руками в терминале. Чтение без повторения навыка не даёт — держите терминал открытым рядом с этим текстом. Как работать с этим курсом: идите сверху вниз, не перепрыгивайте разделы; каждую команду набирайте руками, а не копируйте; в конце каждого блока выполняйте задание; специально ломайте систему в виртуалке и чините — это лучший способ учиться. https://github.com/justxor/linuxfullroadmap/

✔️ Go-ошибки - это не просто `err != nil`, а история о том, что именно сломалось. В Go у ошибок по умолчанию нет stack trace, как в Java или других языках. Поэтому контекст нужно добавлять руками: ошибка пришла из базы, из репозитория, из сервиса, из handler - и каждый слой должен аккуратно объяснить, что происходило. Когда команда делает это хорошо, получается понятная цепочка: unable to get user: failed to query users table: connection refused Когда плохо - в логах остаётся просто connection refused, и потом никто не понимает, где именно это произошло. Проблема в том, что такой контекст надо постоянно поддерживать. Код меняется, старые сообщения устаревают, кто-то забывает завернуть ошибку, и история разваливается. Автор предлагает практичный компромисс: добавлять stack trace в момент, когда приложение создаёт ошибку или впервые получает её от сторонней библиотеки. Тогда у команды всегда есть базовая точка опоры, а ручной контекст можно добавлять там, где он действительно нужен. Хорошие ошибки в Go должны не просто сообщать, что всё упало. Они должны рассказывать, как именно оно к этому пришло. https://robinsiep.com/blog/posts/go-errors/ #golang

CF-Hero: инструмент для проверки, не светит ли ваш origin IP за Cloudflare Cloudflare часто воспринимают как щит, который полностью прячет реальный сервер. Но на практике всё ломается о старые DNS-записи, забытые поддомены, TXT-записи, сторонние индексы и следы в Shodan, Censys или SecurityTrails. CF-Hero как раз собирает такие сигналы в одном месте. Это OSINT-инструмент на Go, который ищет потенциальные origin IP у веб-приложений за Cloudflare и затем проверяет найденные адреса по ответам, чтобы снизить количество ложных совпадений. Что использует: - активный DNS-перебор - Censys, Shodan и ZoomEye - исторические записи SecurityTrails - корреляцию связанных доменов - анализ ответов найденных адресов Если реальный IP где-то уже засветился, CDN перестаёт быть полноценным барьером: сервер могут пытаться атаковать напрямую, в обход правил, WAF и rate limiting. Lang: Go GitHub: https://github.com/musana/CF-Hero