Golang
admin - @notxxx1 https://t.me/golangl - golang чат https://t.me/golangtests go тесты https://t.me/ai_machinelearning_big_data машинное обучение @itchannels_telegram РКН: clck.ru/3Fmx3s #VRHSZ
Ko'proq ko'rsatish📈 Telegram kanali Golang analitikasi
Golang (@golang_google) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 40 412 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 3 213-o'rinni va Rossiya mintaqasida 15 618-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 40 412 obunachiga ega bo‘ldi.
31 Avgust, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 73 ga, so‘nggi 24 soatda esa 35 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 22.31% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 10.11% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 9 008 marta ko‘riladi; birinchi sutkada odatda 4 081 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 52 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent golang, api, devops, github, аллокация kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“admin - @notxxx1
https://t.me/golangl - golang чат
https://t.me/golangtests go тесты
https://t.me/ai_machinelearning_big_data машинное обучение
@itchannels_telegram
РКН: clck.ru/3Fmx3s
#VRHSZ”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 01 Sentabr, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
encoding/json/v2 вошёл в стандартную библиотеку
- появился встроенный пакет uuid
- новый профиль goroutineleak помогает искать зависшие goroutine
- выделение небольших объектов ускорили до 30%
- добавили экспериментальный portable SIMD
- go doc теперь поддерживает package@version
- go mod tidy лучше упорядочивает require
Удобная подборка всех изменений Go 1.27 с примерами и ссылками на документацию:
https://antonz.org/go-features/#1.27MapList(list, fn)
Теперь можно писать естественнее:
list.Map(fn).Map(fn2)
Пример:
func (List[E]) Map[R any](f func(E) R) List[R]
Это делает generic-код компактнее, улучшает цепочки вызовов и позволяет держать связанную логику рядом с самим типом.
При этом generic methods для интерфейсов пока не поддерживаются - из-за сложностей с генерацией и вызовом конкретных реализаций.
https://go.dev/blog/generic-methodssync.Map официально работает на базе hash trie. Публичный API не изменился, но внутри теперь совсем другая структура.
Как это устроено:
* ключ хешируется в 64 бита
* хеш разбивается на группы по 4 бита
* каждый узел trie имеет до 16 потомков
* lookup проходит по дереву максимум 16 уровней
* структура снижает конкуренцию вокруг одного глобального lock
Но sync.Map всё ещё не универсальная замена обычному map: в тестах статьи он потреблял примерно в 3-5 раз больше памяти.
Использовать его имеет смысл, когда значения в основном один раз записываются и много читаются или goroutine работают преимущественно с разными ключами. В остальных случаях map + Mutex/RWMutex часто проще и лучше.
Очень подробный разбор реализации:
https://victoriametrics.com/blog/go-sync-map-hash-trie/
pumba --interval=30s --random kill "re2:^test"
убивать контейнеры,
pumba netem --duration 5m delay --time 3000 mydb
добавлять сетевую задержку,
pumba iptables --duration 2m loss --probability 0.1 myapp
терять пакеты,
pumba stress --duration 60s --stressors="--cpu 4 --timeout 60s" mycontainer
и нагружать CPU, память или I/O.
Есть ещё pause, restart, rm, ограничение скорости сети, corruption/duplication пакетов, выбор контейнеров по regex и периодические сценарии через --interval.
GitHub: https://github.com/alexei-led/pumbaДанил Руденко, 2ГИС — «Репозиторий здорового человека» Зачем нужен паттерн «Репозиторий», почему не стоит тащить в него бизнес-логику, с какими сложностями можно столкнуться при работе с транзакциями и как их решать. Никита Метелкин, Cloud.ru — «Как написать свой плагин для protoc-gen-go» Как устроен protoc и как с помощью Go и protogen генерировать собственный код из .proto-файлов. Александр Бухалко, MWS Cloud Platform — «Взросление OpenAPI-кодогенерации» Почему одной модели для запроса и ответа может быть мало, как внедрять частичное обновление данных, переходить на OpenAPI 3.1 и работать с полями в Go и Kotlin.Приходите на наши следующие мероприятия. У нас хорошо Другие инженерные инсайты от 2ГИС → в Telegram-канале RnD
pumba --interval=30s --random kill "re2:^test"
убивать контейнеры,
pumba netem --duration 5m delay --time 3000 mydb
добавлять сетевую задержку,
pumba iptables --duration 2m loss --probability 0.1 myapp
терять пакеты,
pumba stress --duration 60s --stressors="--cpu 4 --timeout 60s" mycontainer
и нагружать CPU, память или I/O.
Есть ещё pause, restart, rm, ограничение скорости сети, corruption/duplication пакетов, выбор контейнеров по regex и периодические сценарии через --interval.
GitHub: https://github.com/alexei-led/pumbago-linq показал новую версию библиотеки для Go 1.27, которая позволяет писать типобезопасные цепочки запросов в стиле LINQ:
From(users).
Where(...).
Join(...).
ToSlice()
Главная цель проекта - получить удобство LINQ без привычной цены в виде большого runtime-overhead.
По словам автора, производительность уже близка к вручную написанным циклам, а дальше её планируют ещё улучшать.
GitHub: https://github.com/ahmetb/go-linq goroutineleak в pprof, который помогает находить навсегда зависшие goroutine.
В стандартной библиотеке появился encoding/json/v2 с более строгими настройками и новым streaming API. Старый encoding/json теперь использует v2 внутри для более быстрого unmarshaling, сохраняя обратную совместимость.
Также добавили встроенный пакет uuid, поддержку постквантовых подписей ML-DSA и экспериментальный SIMD API.
Из приятного для повседневной работы: go doc теперь понимает package@version, go mod tidy сам приводит несколько require`-блоков в нормальный вид, а `go fix получил новые modernizer'ы.
https://go.dev/blog/go1.27
@Golang_googleskill-up - инструмент на Go для тестирования и прокачки skills у AI-агентов.
Вместо папок с разрозненными промптами, скриптами и eval-файлами здесь используется декларативный YAML-формат. Skill можно описать как конфиг и гонять одинаково локально или в CI.
Поддерживаются три стратегии оценки: обычные правила, скрипты и judge на базе другого агента. Есть совместимость с форматом Anthropic и импорт evals.json.
Здесь есть интересный цикл улучшения: skill-up может находить провальные кейсы, помогать расширять eval-набор и итеративно чинить сам skill.
То есть идея примерно такая: написал skill → прогнал eval → увидел, где агент ломается → обновил → снова прогнал.
https://github.com/alibaba/skill-up
#AI #Golang #AgenticAI #DevOpskubectl get
kubectl describe
kubectl logs
kubectl events
можно сразу увидеть:
• граф связей между сервисами и ресурсами
• состояние Deployment, Pod, Service и Ingress
• события и историю изменений
• Helm-релизы
• GitOps-состояние Argo CD и Flux
• проблемы с ресурсами
Radar работает как один Go-бинарник с встроенным React-интерфейсом. Не требует установки агентов в кластер, использует существующий kubeconfig и может запускаться локально.
Проект полностью open-source под Apache 2.0. Есть запуск через kubectl radar, Homebrew, Krew или Helm.
По сути, это попытка сделать современную замену старым Kubernetes Dashboard и тяжёлым GUI-инструментам: быстро, локально и без лишней инфраструктуры.
GitHub:
https://github.com/skyhook-io/radaros.ReadFile(), ставим программу на паузу и смотрим RSS процесса.
b, err := os.ReadFile("bigfile.txt")
if err != nil {
panic(err)
}
fmt.Println(len(b))
fmt.Scanln()
Ожидаем около 500 МБ RSS.
А видим условные 3 МБ.
На первый взгляд кажется, что os.ReadFile() ничего не загрузил. Но причина совсем другая.
[]byte - это только descriptor:
slice
├─ ptr ───────────┐
├─ len │
└─ cap │
▼
+-------------------+
| 500 MB byte array |
+-------------------+
Сам slice header на 64-битной системе занимает всего несколько машинных слов. Основные 500 МБ находятся в backing array на heap.
Ключевой момент - liveness analysis.
После:
fmt.Println(len(b))
fmt.Scanln()
переменная b больше не используется.
Для Go это означает, что объект может перестать считаться live ещё до выхода main(). GC получает право освободить backing array, пока программа всё ещё ждёт Enter.
Добавим обращение после паузы:
fmt.Scanln()
fmt.Println(b[0])
И RSS внезапно становится примерно равен размеру файла.
Это хороший пример того, почему:
scope переменной != время жизни объекта для GC.
Чтобы явно сохранить объект живым до определённой точки, в низкоуровневом коде существует:
runtime.KeepAlive(b)
Но использовать KeepAlive просто ради красивого RSS обычно не нужно - он важен прежде всего при работе с finalizer, unsafe, syscall и foreign memory.
Ещё одна ловушка - go run.
go run main.go bigfile.txt
сначала компилирует временный binary, а затем запускает его отдельным процессом. Поэтому смотреть память нужно у процесса вида:
/tmp/go-build.../exe/main
а не у самого go run.
Практический вывод для production:
data, _ := os.ReadFile(path)
подходит для небольших файлов, но большой файл означает большую аллокацию, давление на heap и GC.
Для потоковой обработки лучше:
f, err := os.Open(path)
if err != nil {
return err
}
defer f.Close()
r := bufio.NewReaderSize(f, 256<<10)
или вообще:
_, err = io.Copy(dst, f)
Тогда объём рабочей памяти зависит от размера буфера, а не от размера файла.
Главный урок: RSS показывает состояние процесса в конкретный момент, а не полную историю его аллокаций.
И если профилируете память Go-приложения, одного ps мало - смотрите ещё heap profile, runtime.MemStats и GODEBUG=gctrace=1.gofmt приводит код к одному виду, стандартная библиотека закрывает огромный пласт задач, а компилятор быстро ловит выдуманные методы, неправильные типы и другие типичные ошибки LLM.
Для AI-агента это особенно удобно. Сгенерировал код, запустил компилятор и тесты, получил ошибку, исправил, повторил.
Рядом уже лежат fuzzing, govulncheck, gopls, go fix, профилирование и tracing. Агенту не приходится каждый раз собирать собственный зоопарк инструментов.
Есть и менее очевидный бонус. Go-код в разных проектах обычно выглядит похоже.
Меньше вариантов выразить одну и ту же конструкцию, меньше сюрпризов при ревью, проще заметить галлюцинацию модели или странную зависимость.
Для мира, где код начинают генерировать в огромных объёмах, такая предсказуемость становится очень дорогим преимуществом.
Получается забавно: Go долго критиковали за скучный синтаксис, жёсткие правила и отсутствие лишней магии. А теперь именно эти качества неожиданно делают его одним из самых удобных языков для работы с coding agents.
Похоже, в эпоху AI самый модный язык может оказаться тем, который годами специально пытался быть скучным.
https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/
#Golang #Go #AI #Programming #AIAgents
type Box[T any] struct {
Value T
}
func (b Box[T]) Map[R any](fn func(T) R) Box[R] {
return Box[R]{fn(b.Value)}
}
Это открывает новые возможности для обобщённых библиотек.
⚡ Улучшения работы с памятью
Компилятор получил оптимизации для маленьких аллокаций.
Результат:
- меньше overhead при создании объектов;
- быстрее работа с большим количеством мелких структур;
- улучшения для allocation-heavy приложений.
📦 Новый encoding/json/v2
Появляется экспериментальная новая версия JSON-пакета:
import "encoding/json/v2"
Цель - решить старые ограничения encoding/json и сделать работу с JSON более современной.
🔍 Улучшения runtime
Изменения затронули:
- профилирование goroutine;
- trace;
- таймеры;
- внутренние оптимизации runtime.
Go 1.27 показывает привычный подход команды Go:
меньше магии - больше предсказуемости и производительности в production.
Не революция, а очередная шлифовка языка, который уже лежит в основе Kubernetes, облаков и высоконагруженных систем.
Подробнее:
https://victoriametrics.com/blog/go-1-27/
osv-scanner scan source -r .
И он рекурсивно найдёт go.mod, package.json, pom.xml, lock-файлы и другие поддерживаемые форматы, после чего покажет известные уязвимости.
Поддерживаются:
- Go, Python, Rust, Java, JavaScript, C/C++ и другие экосистемы;
- npm, pip, Maven, Cargo, Go Modules, NuGet и другие менеджеры;
- Linux-пакеты;
- container images;
- offline-сканирование;
- анализ вызовов, чтобы уменьшать число ложных срабатываний;
- рекомендации по обновлению уязвимых зависимостей.
Под капотом используется OSV-Scalibr, а данные приходят из открытой OSV-базы, которая агрегирует GitHub Security Advisories, RustSec, Ubuntu Security Notices и другие источники.
Установка из исходников:
go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest
Полезный инструмент для CI/CD и контроля software supply chain без тяжёлых коммерческих платформ.
Источник:
https://github.com/google/osv-scanner
#Golang #CyberSecurity #DevOps #OpenSource
33.3 → 33
33.3 → 33
33.4 → 33
Итого: 99%
Для простого интерфейса можно округлить первые значения, а последнему передать остаток:
package main
import "math"
func balancePercentages(values []float64) []int {
if len(values) == 0 {
return nil
}
result := make([]int, len(values))
used := 0
for i := 0; i < len(values)-1; i++ {
result[i] = int(math.Round(values[i]))
used += result[i]
}
result[len(values)-1] = 100 - used
return result
}
Результат:
[]int{33, 33, 34}
Сумма останется равной 100.
Но это быстрый приём, а не универсальный алгоритм:
- значения должны быть заранее нормализованы;
- вся погрешность достаётся последнему элементу;
- результат зависит от порядка;
- при некорректных данных последнее значение может стать отрицательным.
Для справедливого распределения лучше использовать метод наибольших остатков: округлить всё вниз, а недостающие единицы отдать значениям с крупнейшей дробной частью.
Код актуален для современной Go 1.26 и работает без изменений. Функция math.Round доступна начиная с Go 1.10.