Go for Devs – Telegram
Go for Devs
1.07K subscribers
49 photos
17 videos
64 links
По сотрудничеству пишите в личные сообщения канала.
Download Telegram
🗑 Сборщик мусора в Go. Часть 2: GC Traces

В новой статье узнайте, как оптимизация аллокаций в Go может снизить нагрузку на сборщик мусора и ускорить приложение почти в два раза.

На примере реального веб-приложения разбираемся, как профилировать кучу, находить «горячие» места и убирать лишние аллокации, чтобы снизить задержки и повысить пропускную способность.

📚 Подробности на Хабр: https://habr.com/ru/articles/948864/

Первая статья из серии.
Please open Telegram to view this post
VIEW IN TELEGRAM
5🔥5👍2
🔧 Go + Valgrind: Почему это важно и как это работает?

Если вы разрабатываете низкоуровневый код или работаете с cgo, вам знакомы проблемы с отслеживанием использования памяти и выявлением багов. А вот теперь, внимание: в Go добавили поддержку Valgrind! Должно быть интересно для тех, кто хочет глубже проанализировать поведение программы на уровне памяти.

Теперь в Go появились аннотации, которые позволяют интегрировать программу с Valgrind, избегая ложных срабатываний, с которыми сталкивались разработчики раньше.

Как это работает? Встроенная в Go сборка теперь будет использовать инструментальные аннотации для отслеживания использования памяти. Вместо того чтобы добавлять заголовки Valgrind в код и полагаться на cgo, разработчики добавили функцию ассемблера, которая генерирует нужные инструкции для клиентских запросов Valgrind. То есть, теперь можно отслеживать стек и пулы памяти в Go-коде, а это, скажем прямо, не всегда легко для инструментов, которые привыкли к стандартному libc.

Зачем это вообще нужно? С помощью Valgrind теперь можно проанализировать, как Go управляет памятью на уровне рантайма. Это откроет новые возможности для мониторинга, поиска утечек памяти и проверки работы криптографических алгоритмов в постоянном времени. Так, например, Go активно использует алгоритмы шифрования в криптографическом дереве. До сих пор не было удобного способа удостовериться, что эти алгоритмы не подвержены тайминг-атакам, но теперь с Valgrind можно будет замерить, нет ли нежелательных зависимостей от времени выполнения операций.

Но стоит отметить, что пока это экспериментальная фича. Разработчики предлагают включить флаг -valgrind, чтобы протестировать нововведения, и при этом признают, что реализация пока не идеальна. Например, если запустить даже простую программу, Valgrind всё равно обнаружит несколько сотен ошибок, из-за отсутствия понимания, как Go работает с памятью. Однако с корректным использованием флагов можно минимизировать эти проблемы и максимально использовать возможности инструмента.

P.S. Примечательно, что поддержка Valgrind в Go прошла мимо обычного процесса обсуждений 😅

Закрытый issue на GitHub
Review PR
Valgrind
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥52
⚡️ Кэширование в Go: ускоряем API без Redis

В статье разбираются основные стратегии кэширования — от Write-Through до Write-Back — и показан пример реализации кэша с TTL на чистом Go.

Отличный материал, если хотите ускорить свой сервис без перехода на Redis.

📚 Подробности на Хабр: https://habr.com/ru/articles/948866/
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍3🔥3
🔥 PostgreSQL 18: быстрее в 3 раза без переписывания SQL

На днях вышла новая версия PostgreSQL — и она серьёзно прокачала производительность и удобство работы с БД.

Новая асинхронная I/O подсистема ускоряет до 3х раз чтение данных.
Апгрейды между мажорными версиями теперь станут менее болезнеными — статистика запросов сохраняется, и база не «тупит» после обновления.
Про разработчиков тоже не забыли: виртуальные вычисляемые колонки, умные индексы со skip scan, новый uuidv7() с лучшей производительностью.
Поддержка OAuth 2.0 для аутентификации, более быстрая логическая репликация и улучшенная работа с текстом.

PostgreSQL продолжает эволюционировать. И это радует)

Release Notes на английском
Release Notes на русском
Видео-обзор на русском от Павла Лузанова
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12👍53
😎 Flight Recorder в Go 1.25 – точечная диагностика без лишних трассировок

В Go 1.25 появился новый инструмент диагностики — flight recorder. Он позволяет заглянуть в последние секунды работы приложения уже после того, как произошла проблема, и точно понять, что случилось «под капотом».

Отличный способ находить тонкие баги и задержки в долгоживущих сервисах без гигабайтов бесполезных трассировок.

📚 Подробности на Хабр: https://habr.com/ru/articles/951216/
👍8🔥52
🐘 Что нового в PostgreSQL 18? Взгляд разработчика

Новый релиз не ограничился громкой подсистемой асинхронного ввода-вывода — он принёс ряд функций, заметных именно в повседневной разработке.

Нативная поддержка UUID v7, виртуальные генерируемые столбцы, расширенные возможности RETURNING и новые средства диагностики делают жизнь разработчиков проще и продуктивнее.

📚 Подробности на Хабр: https://habr.com/ru/articles/951802/
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥841👍1
Forwarded from AI for Devs
This media is not supported in your browser
VIEW IN TELEGRAM
JetBrains встроили Claude Agent прямо в свои IDE

Claude Agent теперь живёт прямо в AI-чате IDE, а под капотом — свежевыпущенный Claude 4.5 Sonnet.

Примечательно, что это первый сторонний агент, официально встроенный в экосистему JetBrains, и он идёт в составе подписки JetBrains AI — доплат не просят. Сделан на Anthropic Agent SDK, поэтому умеет в контекст, тулы, файловые операции и даже исполнение кода. Работает через MCP: агент видит IDE как сервер инструментов, вы — просто переписываетесь в чате.

Кратко об основных возможностях:

🟣 Работа с несколькими файлами: агент показывает предложенные правки в виде диффов прямо в редакторе — удобно сравнить «до/после» и решить, принять или выкинуть.
🟣 Контроль на вашей стороне: без вашего разрешения Claude ничего не тронет — ни файл, ни консоль. Но если достаточно смелые, то можно включить Brave mode и агент пойдет заниматься своими делами без ваших апрувов
🟣 Plan mode: агент сначала опишет шаги и только потом займется реализацией.
🟣 Управление контекстом: можно подкинуть файлы, папки или даже картинки — агент станет отвечать точнее и умнее.

Источник

@ai_for_devs
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥62👍1👎1
🤬 Почему Go до сих пор меня раздражает?

Ошибки на миллиард долларов, загадочный nil, проблемы с памятью и «магия» defer — по мнению автора, всё это делает язык излишне сложным и болезненным.

А стоит ли оно того?

📚 Подробности на Хабр: https://habr.com/ru/articles/951218/
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5😁4👍311👎1
🔥 Coming Soon в Go 1.26: нормальные указатели на значения

Вы точно сталкивались с тем, что указатель на структуру сделать легко, а вот на простое значение вроде int — уже приходится извращаться.


a := 77
b := &a
fmt.Println(*b) // 77


Это работает, но выглядит, мягко говоря, странно.

В Go 1.26 завезут следующее:


a := new(42)
fmt.Println(*a) // 42


То же самое будет работать и для строк, слайсов, даже для результата функции:


s := "hello"
ps := new(s)
fmt.Println(*ps) // hello

type Point struct { X, Y int }
pp := new(Point{X: 5, Y: 7})
fmt.Println(*pp) // {5 7}

f := func() string { return "GoLang" }
pf := new(f())
fmt.Println(*pf) // GoLang


На просторах интернета уже можно найти следующее:

“RIP всем самописным PointerTo[T any](in T) *T — теперь в стандартной библиотеке есть всё необходимое. Маленькое и незаметное изменение, но с огромным профитом.”


Единственный нюанс: new() всегда аллоцирует новое место и кладёт туда копию значения. То есть new(*p) сделает копию того, на что указывает p, а не новый указатель на тот же объект.

👍 Давай еще новостей про грядущий релиз
🔥 Фича топ
👍26🔥12🤔43
😋 Обедающие философы на Go: как не умереть от взаимной блокировки и голодания

В новой статье шаг за шагом решается классическая задача об обедающих философах на Go.

Вы узнаете, почему наивный подход ведёт к взаимной блокировке, как нарушить симметрию, чтобы избежать deadlock’а, и почему даже «рабочее» решение может оставить одного философа голодать вечно.

📚 Подробности на Хабр: https://habr.com/ru/articles/951224/
Please open Telegram to view this post
VIEW IN TELEGRAM
👍43🔥3
🔥 Пишем микросервисы на Go как в BigTech, с нуля

Как эффективно начать разработку микросервисов на Go с использованием современных инструментов, популярных в крупных технологических компаниях. Обсудили ключевые трудности при создании микросервисной архитектуры с нуля, такие как интеграция компонентов, межсервисное взаимодействие и поддержка системы.

Спикер представлил инструменты, которые могут значительно упростить этот процесс:
— gRPC для высокопроизводительного межсервисного взаимодействия;
— gRPC-Gateway для обеспечения совместимости с RESTful API;
— Buf для управления protobuf схемами;
— rk-boot для быстрого старта и стандартизации.

Леонид на практике показал, как эти технологии интегрируют в реальный проект, с акцентом на упрощение разработки и поддержания микросервисов.

В заключение — итоги и рекомендации, как начать внедрение этих инструментов в проекты.

😉 СМОТРЕТЬ НА YOUTUBE
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍32👎1
⚡️ Насколько быстр Go? Симуляция миллионов частиц на смарт-ТВ

Команда Go for Devs подготовила перевод статьи о том, насколько быстрым может быть Go. Автор проверил это на практике — написал симуляцию миллионов частиц с мультиплеером, только на CPU и так, чтобы оно работало даже на смарт-ТВ.

Go оказался одновременно и разочарованием, и восторгом: он не дотягивает до Rust в вычислительных задачах, но удивляет своей простотой и тем, как легко масштабируется до сотен клиентов.

📚 Подробности на Хабр: https://habr.com/ru/articles/953434/
👏5👍4🔥21
Forwarded from AI for Devs
🐳 У Docker тоже есть свой агент — Gordon!

Кажется, многие пропустили, но релиз этого помощника состоялся уже какое-то время назад. Да, теперь и Docker не отстаёт от моды на ИИ — в Desktop и CLI появился собственный агент под именем Gordon. Отставить шуточки!

Gordon — это встроенный AI-ассистент, который умеет анализировать Dockerfile, искать ошибки, оптимизировать сборку, чинить контейнеры и даже мигрировать их на более безопасные Docker Hardened Images. Короче, если ваш контейнер внезапно “упал”, можно просто спросить:

docker ai "почему он упал?"


Идея логичная: собрать по-настоящему production-ready Dockerfile — задача не для слабонервных. Сотни нюансов, best-практики, уязвимости, кэш, слои, образы — на всё это Gordon теперь может хотя бы намекнуть.

Gordon встроен в Docker Desktop 4.38+ и CLI, но пока сидит в бете. Чтобы включить — надо активировать “Docker AI” в настройках. Конечно, Docker подчёркивает: данные шифруются, а запросы не используются для обучения моделей. Верим...

Документация
Блог-пост анонс
Демо на YouTube

@ai_for_devs
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥62😁2🤔1🤯1
👥 Группировка сабтестов в Go: от простого к сложному

Команда Go for Devs подготовила перевод статьи о том, как правильно группировать сабтесты в Go.

Автор показывает, что в большинстве случаев достаточно держать тесты плоскими, а когда нужна разная инициализация и очистка — добавить лишь один уровень вложенности.

В статье разбираются плюсы и минусы разных подходов: от ручных t.Run до reflection-хаков и сторонних библиотек.

📚 Подробности на Хабр: https://habr.com/ru/articles/953418/
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥42
🤨 Goiaba: Go-компилятор на Rust

Raph Amorim решил написать компилятор для Go… на Rust. Проект называется Goiaba (в переводе с португальского — гуава), и это пока эксперимент, но довольно показательный.
Автор известен по вкладам в экосистему WebAssembly и Wasmer. Его цель — исследовать, насколько реально собрать полноценный Go-компилятор с нуля на Rust, не используя LLVM, TinyGo или классический toolchain от Google.

• Goiaba написан на чистом Rust, без зависимостей от существующих Go-компиляторов.
• Потенциально может использоваться как библиотека внутри Rust-проектов.
• Может компилировать Go-код в WebAssembly, как TinyGo, но с иным подходом к архитектуре.
• Сообщество уже спорит, сможет ли он быть быстрее официального Go-компилятора (сомнительно, но Rust даёт шанс на более безопасные оптимизации).

На Hacker News обсуждение быстро скатилось в старую добрую войну “Rust vs Go”: кто быстрее компилирует.

> Скорость компиляции — не то, о чём я переживаю в Go. В отличие от Rust, с которым я почти не работаю — в том числе именно из-за скорости компиляции.

> Меня реально удивляет, что люди до сих пор жалуются на скорость компиляции Rust. Я работал с довольно большими проектами — отладочная сборка занимает несколько секунд, релизная — меньше минуты. Это точно не хуже, чем сборка TypeScript.


Такие эксперименты — тест на гибкость экосистемы. Появление альтернативных реализаций компиляторов укрепляет экосистему Go и открывает двери к новым сценариям — например, встраиванию Go в Rust-приложения или кроссплатформенным билдам без LLVM.

Репозиторий на GitHub
Обсуждение на Hacker News

@go_for_devs
🔥8👍52😁1
Forwarded from Cross Join - канал о разработке (Anton Okolelov)
Не, ну какие контрол-фрики эти правила придумывают

Может, еще пробелы по штангенциркулю подравнять?
😁9👍3😱3
🗑 Сборщик мусора в Go. Часть 3: Управление скоростью GC

Команда Go for Devs подготовила перевод статьи о том, как в Go устроено управление скоростью работы сборщика мусора.

TL;DR: даже при тысячах горутин GC подстраивается под нагрузку, выбирая между меньшим числом долгих пауз и большим числом коротких.

Итог — разработчику почти не нужно вручную «крутить» настройки, рантайм сам находит оптимальный ритм.

📚 Подробности на Хабр: https://habr.com/ru/articles/953426/

Первая статья из серии.
Вторая статья из серии.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥31
🪲 Cloudflare нашли редчайший баг — прямо в компиляторе Go для ARM64!

Да, это не опечатка: не рантайм, не race condition в их коде, а чистый косяк в сгенерированном машинном коде Go. И баг был настолько редким, что проявиться он мог только в инфраструктуре масштаба Cloudflare — при 84 миллионах HTTP-запросов в секунду.

На ARM64-машинах Cloudflare стали вылезать странные паники вроде traceback did not unwind completely — ошибка, указывающая на повреждённый стек при попытке раскрутки. Поначалу инженеры списали это на баг в старом коде с panic/recover, потом — на библиотеку Go Netlink. Но когда даже без неё паники продолжились, стало ясно: проблема глубже.

После недель отладки выяснилось: краш происходит при асинхронном вытестении (введённом в Go 1.14), когда рантайм прерывает горутину между двумя машинными инструкциями, корректирующими указатель стека. В этот момент стек оказывается в «разрезанном» состоянии — раскрутчик стека получает некорректный указатель и падает.

Инженеры написали минимальный Go-пример, где функция с большим стеком (>64 КБ) порождает тот самый двойной ADD. После пары минут работы программа стабильно умирала с SIGSEGV. Без сторонних библиотек. Только чистый Go.

package main

import (
"runtime"
)

//go:noinline
func big_stack(val int) int {
var big_buffer = make([]byte, 1 << 16)

sum := 0
// предотвращаем оптимизацию стека компилятором
for i := 0; i < (1<<16); i++ {
big_buffer[i] = byte(val)
}
for i := 0; i < (1<<16); i++ {
sum ^= int(big_buffer[i])
}
return sum
}

func main() {
go func() {
for {
runtime.GC()
}
}()
for {
_ = big_stack(1000)
}
}

Разобравшись, они подтвердили: это ошибка в компиляторе Go, который на ARM64 разбивает корректировку стека на две инструкции, не учитывая возможность асинхронного вытеснения между ними.

Go-команда признала баг и исправила его в версиях go1.23.12, go1.24.6 и go1.25.0.

Получается, даже компиляторы ошибаются) Просто чтобы поймать такой баг, нужно немного — пара сотен дата-центров и десятки миллионов запросов в секунду.

Источник

@go_for_devs
👍10🔥9🤯61
Как структурировать маршруты в Gin

При разработке веб-API у вас часто бывает множество конечных точек, логически связанных между собой. Например, один набор маршрутов — для управления пользователями, другой — для работы с товарами, третий — для обработки заказов. Без должной организации ваш код быстро превращается в хаотичный набор маршрутов, который трудно читать, сопровождать и развивать.


r.GET("/books", getBooks)
r.POST("/books", createBook)
r.GET("/members", getMembers)
r.POST("/members", createMember)


Здесь на помощь приходит группировка маршрутов. Она позволяет объединять связанные маршруты под общим префиксом пути. Представьте, что вы создаёте «папки» для маршрутов: каждая группа содержит набор конечных точек, которые относятся друг к другу. Это не только повышает читаемость кода, но и упрощает применение общего поведения (например, middleware) к определённым группам маршрутов.


package main

import (
"github.com/gin-gonic/gin"
)

func main() {
r := gin.Default()

// Grouping book-related routes
bookGroup := r.Group("/books")
{
bookGroup.GET("/", getBooks)
bookGroup.POST("/", createBook)
}

// Grouping member-related routes
memberGroup := r.Group("/members")
{
memberGroup.GET("/", getMembers)
memberGroup.POST("/", createMember)
}

r.Run()
}


Заметьте, насколько чище стало: все маршруты, связанные с книгами, сгруппированы под /books, а все, связанные с читателями, — под /members. Это упрощает навигацию по коду и понимание его структуры.

📚 Подробности на Хабр: https://habr.com/ru/articles/955802/
Please open Telegram to view this post
VIEW IN TELEGRAM
👍74🔥2🤯1