Golang
admin - @haarrp https://t.me/golangl - golang чат https://t.me/golangtests go тесты https://t.me/ai_machinelearning_big_data машинное обучение @itchannels_telegram РКН: clck.ru/3Fmx3s #VRHSZ
Показати більше📈 Аналітичний огляд Telegram-каналу Golang
Канал Golang (@golang_google) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 40 481 підписників, посідаючи 3 292 місце в категорії Технології та додатки та 15 628 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 40 481 підписників.
За останніми даними від 18 жовтня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на 24, а за останні 24 години на 9, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 19.38%. Протягом перших 24 годин після публікації контент зазвичай збирає 9.32% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 7 847 переглядів. Протягом першої доби публікація в середньому набирає 3 775 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 39.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як golang, api, devops, github, аллокация.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“admin - @haarrp
https://t.me/golangl - golang чат
https://t.me/golangtests go тесты
https://t.me/ai_machinelearning_big_data машинное обучение
@itchannels_telegram
РКН: clck.ru/3Fmx3s
#VRHSZ”
Завдяки високій частоті оновлень (останні дані отримано 19 жовтня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
resp.Body.Close() было недостаточно: если тело ответа не дочитано, соединение приходилось закрывать. Следующий запрос снова тратил время на TCP и TLS.
Теперь net/http при закрытии тела асинхронно дочитывает остаток в пределах установленного лимита, чтобы сохранить соединение для следующих запросов.
В тесте авторов статьи 100 запросов, которым нужен только статус ответа, заняли 150 мс вместо 710 мс. Почти пятикратное ускорение в конкретном сценарии, без изменений кода.
Закрывать `resp.Body` по-прежнему обязательно. Изменение касается HTTP/1: у HTTP/2 непрочитанное тело отдельного ответа не мешает другим запросам использовать соединение.
https://uproger.com/go-1-27-http1/
#golangIngress и EndpointSlice, отслеживая маршруты и адреса бэкендов.
• Rust-движок на Tokio принимает трафик и ищет маршруты в конкурентной таблице DashMap.
Обработка запросов отделена от взаимодействия с Kubernetes API.
Первый нагрузочный тест выглядел обнадёживающе только по счётчику соединений: движок принимал около 55 тысяч в секунду, но не отдавал успешных ответов.
Причина оказалась в разборе конфигурации. Вместо JSON-парсера код искал точную подстроку:
Ожидал: "host":"silex.local"
Получил: "host": "silex.local"
Допустимый в JSON пробел ломал поиск. Обработчик молча завершался и закрывал TCP-соединение. Итог: 1,8 млн ошибок чтения.
После исправления автор сравнил Silex с NGINX Ingress: K3s, HTTP echo-бэкенд, wrk, 400 соединений, 4 потока, 30 секунд.
Silex: 2536 запросов/с. NGINX: 2274. Разница: +11,5%.
Но максимальная задержка у обоих была около двух секунд, таймауты тоже остались. У Silex их даже больше: 302 против 286. По объяснению автора, нагрузка упёрлась в Node.js-бэкенд.
На момент статьи TLS-терминация, активные проверки бэкендов и Prometheus-метрики ещё были в планах.
Самое ценное здесь: увидеть, как устроен небольшой ingress, где ломается взаимодействие компонентов и почему throughput нужно читать вместе с ошибками и задержками.
https://dev.to/sysalchemist/how-i-built-a-custom-kubernetes-ingress-in-rustgo-that-outperforms-nginx-by-11-4iagХорош бояться Кафку: ломаем и чиним Go-сервис в прямом эфиреПредыстория такая: пока меня не было дома, мой кот Коткинс добрался до телефона и начал заказывать себе вкусняшки с моей карты. Приложение кидает заказ в Кафку, сервис оплаты читает его и списывает деньги. Вот эту систему и будем ломать) Что разберём на уроке: 🟢Без занудных определений разберёмся, что такое продюсер, топик, партиции, группа и смещение. Просто проследим один заказ в Kafka UI от кнопки до списания 🟢Трижды попробуем сломать систему: потеряем заказ, спишем деньги дважды и завалим очередь. И разберёмся, почему так вышло 🟢По каждой поломке посмотрим, какие есть варианты починки и чем плох каждый 🟢Попросим нейронку написать консюмер для оплаты и посмотрим, переживёт ли он повтор сообщения 🟢Расскажу, когда Кафка вообще не нужна и можно спокойно взять RabbitMQ 🟢В конце отдам репозиторий со всем кодом урока, чтобы ты мог повторить всё у себя 🟢И конечно же, анонсирую новый поток своего курса по микросервисам на Go Регистрироваться никуда не надо, ссылка на урок будет прямо в канале по микросервисам: Залететь в канал с уроком P.S. Записи не будет, поэтому жду всех в онлайне) Реклама. ИП Козырев Олег Вячеславович, ИНН 440315249608, erid: 2W5zFJND9EZ
Ingress и EndpointSlice, отслеживая маршруты и адреса бэкендов.
• Rust-движок на Tokio принимает трафик и ищет маршруты в конкурентной таблице DashMap.
Обработка запросов отделена от взаимодействия с Kubernetes API.
Первый нагрузочный тест выглядел обнадёживающе только по счётчику соединений: движок принимал около 55 тысяч в секунду, но не отдавал успешных ответов.
Причина оказалась в разборе конфигурации. Вместо JSON-парсера код искал точную подстроку:
Ожидал: "host":"silex.local"
Получил: "host": "silex.local"
Допустимый в JSON пробел ломал поиск. Обработчик молча завершался и закрывал TCP-соединение. Итог: 1,8 млн ошибок чтения.
После исправления автор сравнил Silex с NGINX Ingress: K3s, HTTP echo-бэкенд, wrk, 400 соединений, 4 потока, 30 секунд.
Silex: 2536 запросов/с. NGINX: 2274. Разница: +11,5%.
Но максимальная задержка у обоих была около двух секунд, таймауты тоже остались. У Silex их даже больше: 302 против 286. По объяснению автора, нагрузка упёрлась в Node.js-бэкенд.
На момент статьи TLS-терминация, активные проверки бэкендов и Prometheus-метрики ещё были в планах.
Самое ценное здесь: увидеть, как устроен небольшой ingress, где ломается взаимодействие компонентов и почему throughput нужно читать вместе с ошибками и задержками.
https://dev.to/sysalchemist/how-i-built-a-custom-kubernetes-ingress-in-rustgo-that-outperforms-nginx-by-11-4iag
-- неймспейсы Kubernetes без NetworkPolicy
select n.name
from kubernetes_namespace n
left join kubernetes_network_policy p on p.namespace = n.name
where p.name is null;
Как это устроено: внутри встроенный PostgreSQL, а каждый источник данных подключается через плагин. Когда вы делаете запрос, плагин в реальном времени ходит в API и отдаёт строки в Postgres. Никакой выгрузки и отдельной базы.
Для Go-разработчиков самое интересное в том, что и Steampipe, и все его плагины написаны на Go, и свой плагин пишется буквально за вечер. Описываете таблицу и функцию, которая получает данные:
func tableUsers() *plugin.Table {
return &plugin.Table{
Name: "myapi_user",
List: &plugin.ListConfig{Hydrate: listUsers},
Columns: []*plugin.Column{
{Name: "id", Type: proto.ColumnType_STRING},
{Name: "email", Type: proto.ColumnType_STRING},
},
}
}
func listUsers(ctx context.Context, d *plugin.QueryData, _ *plugin.HydrateData) (any, error) {
users, err := apiClient.ListUsers(ctx)
if err != nil {
return nil, err
}
for _, u := range users {
d.StreamListItem(ctx, u) // каждая запись становится строкой таблицы
}
return nil, nil
}
После этого ваш внутренний сервис можно джойнить с AWS, GitHub или Kubernetes одним запросом. Кэширование, параллельные запросы, повторы и лимиты SDK берёт на себя.
Готовых плагинов уже больше сотни, так что для аудита инфраструктуры, поиска забытых ресурсов или проверки, у каких репозиториев нет защиты веток, писать код вообще не придётся.
https://devopscube.com/steampipe-tutorial/
https://github.com/turbot/steampipeТрек Tech: доклады про архитектурные решения, спорные идеи и реальные кейсы. 🎙 Дмитрий Буров, Senior Golang-разработчик, Lamoda Tech «Тернарный оператор в Go. Принять нельзя отклонить» 🎙 Станислав Королев, Senior Golang-разработчик, Авито «Почему spec-driven development плохо работает на микросервисах» 🎙 Эдгар Ситки, Founder, EasyP && Sipki tech «MCP on Go, или Как случайно сломать безопасность вашей системы?»
Трек Activities: круглый стол о будущем Go, «13 злых вопросов» экспертам и игры с призами.🗓 17 октября ⏰ 12:00–18:00 📍 Москва, ул. Крылатская, 15 ➡️ Все подробности и регистрация на сайте Реклама. ООО "ЛАМОДА ТЕХ". ИНН 7734461512. erid: 2W5zFGaEvK3
sync, atomic и memory model;
- runtime, scheduler, escape analysis и GC;
- generics и context.Context;
- HTTP, gRPC, базы данных и брокеры;
- System Design для Middle+/Senior;
- свежие изменения Go 1.22–1.27.
Есть классические задачи вроде Worker Pool, LRU Cache, Rate Limiter, Fan-in, Pipeline, TTL Cache, Singleflight и Graceful Shutdown.
По сути, готовая шпаргалка + задачник + roadmap для подготовки к Go-собеседованию.
https://github.com/justxor/sobesrazborgoogleImageSync CRD, где указываете:
- source registry
- destination registry
- список образов и тегов
- cron-расписание
- способ авторизации
Дальше Portager сам сравнивает digest, копирует только изменившиеся образы и пишет статус обратно в Kubernetes.
Поддерживает Docker Hub, GHCR, Quay, Chainguard, ECR, GCR, Harbor, Nexus и другие OCI-compatible registry.
https://github.com/jarodr47/Portagerstefafafan/jev - неофициальный provider-neutral CLI для Jev от TypeSafe AI, написанный на Go.
Поддерживает:
- TypeSafe AI
- Cloudflare Workers AI
- Vercel AI Gateway
Работает через обычные stdin/stdout, поэтому его удобно встраивать в shell-пайплайны и CI.
Пример проверки diff:
git diff |
jev noul "Could this change introduce a regression?"
Или оценка риска деплоя:
kubectl diff -f manifest.yaml |
jev score \
--level low \
--level medium \
--level high \
"How risky is this deployment?"
Есть три режима:
- noul — yes/no решение;
- choice — выбор варианта;
- score — оценка по уровням.
По умолчанию результат возвращается в JSON.
Установка:
go install github.com/stefafafan/jev@latest
GitHub: https://github.com/stefafafan/jevselect и pipelines;
- context и cancellation;
- WaitGroup, mutex и semaphores;
- data races и race conditions;
- atomics и object pools;
- scheduling, testing и diagnostics.
Каждый пример можно изменить и запустить прямо на странице. Есть и PDF-версия.
Быстрый гайд для тех, кто уже знает Go и хочет систематизировать конкурентность.
По заявлению автора материал полностью AI-free.
Читать: https://antonz.org/go-concurrency-distilled/Int32x4 или Float64x8 используются типы вроде simd.Float32s и simd.Uint8s. Сколько элементов влезет в регистр, 128, 256 или 512 бит, решает железо, на котором запущена программа. Код от этого не меняется.
Набор операций знакомый: загрузка и выгрузка, Add, Mul, MulAdd, сравнения и маски. В пакет попало только то, что есть на всех платформах, а недостающее эмулируется.
Цель авторы формулируют так: писать один раз и получать производительность, близкую к ассемблеру. Компилятор специализирует код под конкретную ширину и убирает накладные расходы на диспетчеризацию внутри вычислений.
Если переносимого набора не хватает, можно спуститься ниже. Методы `ToArch()` и `FromArch()` переводят значения в архитектурно-зависимый пакет archsimd из Go 1.26, где доступны инструкции конкретного процессора. archsimd поддерживает ещё PowerPC, s390x, RISC-V64 и loong64.
Поведение удобно проверять через GODEBUG. Значение simd=0 включает полную эмуляцию, simd=128, 256 или 512 фиксирует ширину вектора, а вариант с плюсом, например simd=+256, частично включает возможности и паникует на отсутствующих инструкциях. Так можно прогнать тесты на всех ширинах на одной машине.
Ограничения тоже есть. В 1.27 нет редукций, поэтому даже сумму элементов вектора придётся собирать обходным путём. В Go 1.28 обещают SVE для ARM, редукции, перестановки элементов, OnesCount и новые операции с масками. Ещё добавят варианты возможностей, чтобы на железе вроде Raspberry Pi код не откатывался в полную эмуляцию из-за одной недостающей инструкции.
Включается всё флагом `GOEXPERIMENT=simd`. Для тех, кто пишет на Go инференс, обработку изображений, кодеки или числодробилки, это первый шанс получить векторизацию без ассемблера и без пачки файлов под каждую архитектуру.
https://go.dev/blog/simd-experiment