Golang

👣 В Go 1.27 появились generic methods Теперь методы конкретных типов могут иметь собственные параметры типов. Раньше для подобных преобразований приходилось выносить логику в отдельную generic-функцию: MapList(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-methods

🔥 В Go полностью переписали внутренности `sync.Map` Начиная с Go 1.26, sync.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/

🖥 Бывший CEO GitHub строит ему замену - и причина в AI-агентах GitHub уже обрабатывает около 2,9 млрд коммитов в месяц - ещё в апреле было 1,4 млрд. За четыре месяца нагрузка почти удвоилась. Каждый месяц: * 130 млн merge pull requests * 24 млн новых репозиториев * миллиарды коммитов Инфраструктура уже не успевает. В этом году GitHub добавил около 3 млн CPU-ядер и 120 ПБ хранилища, а доля нагрузки в Azure выросла с 12% до 58%. Собственные дата-центры упираются уже не столько в бюджет, сколько в доступную мощность. На этом фоне бывший глава GitHub Томас Домке запустил Entire - платформу, которую строят с расчётом на мир, где код пишут не только люди, но и огромные армии AI-агентов. https://thenewstack.io/github-2-9b-monthly-commits/

🐷 Pumba - open source-инструмент для chaos testing Docker, containerd и Podman. По сути, это Chaos Monkey на уровне контейнеров. Он умеет специально ломать окружение: 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

Бархоппинг и разгон факапов? ДА! Атмосферу «ну мёёёёд» сложно передать словами, но мы попробуем! Делимся видео и фоточками с нашего митапа для Go-разработчиков в Нижнем Новгороде. Данил Руденко, 2ГИС — «Репозиторий здорового человека» Зачем нужен паттерн «Репозиторий», почему не стоит тащить в него бизнес-логику, с какими сложностями можно столкнуться при работе с транзакциями и как их решать. Никита Метелкин, Cloud.ru — «Как написать свой плагин для protoc-gen-go» Как устроен protoc и как с помощью Go и protogen генерировать собственный код из .proto-файлов. Александр Бухалко, MWS Cloud Platform — «Взросление OpenAPI-кодогенерации» Почему одной модели для запроса и ответа может быть мало, как внедрять частичное обновление данных, переходить на OpenAPI 3.1 и работать с полями в Go и Kotlin. Приходите на наши следующие мероприятия. У нас хорошо Другие инженерные инсайты от 2ГИС → в Telegram-канале RnD

👣 В Go 1.27 появился почти настоящий LINQ Автор go-linq показал новую версию библиотеки для Go 1.27, которая позволяет писать типобезопасные цепочки запросов в стиле LINQ: From(users). Where(...). Join(...). ToSlice() Главная цель проекта - получить удобство LINQ без привычной цены в виде большого runtime-overhead. По словам автора, производительность уже близка к вручную написанным циклам, а дальше её планируют ещё улучшать. GitHub: https://github.com/ahmetb/go-linq @Golang_google / Папка с полезными Go-ресурсами

👣 Google выпустила Go 1.27. Обновление затронуло язык, runtime, стандартную библиотеку и инструменты разработки. В язык наконец добавили generic methods. Теперь метод может работать сразу с разными типами без отдельных реализаций под int, int32, int64 и другие варианты. Ещё упростили инициализацию embedded-структур и расширили type inference для generic-функций. Runtime тоже ускорили. Для маленьких объектов до 80 байт стоимость аллокаций снизили до 30%, а в allocation-heavy программах это даёт около 1% общей производительности. Появился и новый профиль 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_google

👣 Alibaba выкатила skill-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 #DevOps

🚀 Kubernetes получил новый open-source инструмент для тех, кто устал дебажить кластеры через десятки команд kubectl. Skyhook выпустила Radar - современный UI для Kubernetes, который показывает всю картину кластера в одном месте. Вместо постоянных: kubectl 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/radar

👣 `os.ReadFile()` действительно читает весь файл в память. Но RSS может показать почти ноль - и вот почему Есть интересный эксперимент: читаем файл на 500 МБ через os.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.