Thank Go!

Интерактивный тур по Go 1.26 Опубликовал традиционный тур по будущему релизу (на англ). Часть фич мы с вами уже разобрали, а часть еще разберем, но если хотите прочитать все вместе уже сейчас — добро пожаловать. Вот что вошло: — new(expr) — Безопасная проверка ошибок — Новый «чайный» GC — Ускоренный cgo и выделение памяти — SIMD для amd64 — Секретный режим — Криптография без ридеров — Профиль для ловли утекающих горутин — Метрики состояния горутин — Итераторы в reflect — Подсматривание в байтовы...

Go 1.26: Обновленный go fix С годами команда "go fix" превратилась в свалку покрытых плесенью рефакторингов, которые никто не использует. Сейчас это изменится. В 1.26 go fix переписана с нуля и использует тот же движок, что go vet — но другой набор анализаторов. В отличие от go vet, исправления go fix безопасны (можно применять автоматически) и нацелены больше на модернизацию кода под новые фичи языка и стдлибы, а не исправление проблем в коде. Пример: замена циклов на slices.Contains: // до go ...

Go 1.26: Green Tea GC Новый сборщик мусора (экспериментальный в версии 1.25), в 1.26 будет включен по умолчанию. Мотивация Старый алгоритм сборщика мусора в Go работает с графом: объекты — узлы, а указатели — связи между ними. При этом не учитывается, где именно в памяти находятся эти объекты. Сканер перескакивает между разными участками памяти, из-за чего часто происходят кэш-промахи. В итоге процессор тратит слишком много времени, просто ожидая, когда нужные данные поступят из памяти. Больше 3...

Go 1.26: Быстрое выделение памяти В Go появились специализированные версии функции выделения памяти (allocation) для маленьких объектов (от 1 до 512 байт). Вместо одной универсальной функции теперь выбирается конкретная реализация, в зависимости от размера объекта. В заметках к релизу Go написано: "the compiler will now generate calls to size-specialized memory allocation routines". Но насколько я могу судить, это не совсем так. Компилятор все еще генерирует вызов общей функции mallocgc, а та уж...

Go 1.26 Пссст, там релиз вышел. А мы с вами все интересное из него уже разобрали: — new(expr) — Безопасная проверка ошибок — Новый «чайный» GC — Ускоренный cgo и выделение памяти — SIMD для amd64 — Секретный режим — Криптография без ридеров — Профиль для ловли утекающих горутин — Метрики состояния горутин — Байтовое подсматривание — Сравнение IP-подсетей — Dialer с контекстом — Оптимизированные fmt.Errorf и io.ReadAll — Множественные хендлеры в логах — Обновленный go fix Удачного вам апгрейда :)

Go 1.26: Множественные хендлеры в логах Теперь можно легко писать логи сразу в несколько мест — например, в консоль, файл или на удаленный сервер — с помощью стандартной библиотеки. Все благодаря slog.MultiHandler, который отправляет записи лога всем настроенным обработчикам. Например, создаем хендлер для записи в stdout: stdoutHand := slog.NewTextHandler(os.Stdout, nil) И второй для записи в файл: const flags = os.O_CREATE | os.O_WRONLY | os.O_APPEND file, err := os.OpenFile("/tmp/app.log", fla...

Утечки горутин в Go 1.24+ Вы конечно и так в курсе, но на всякий случай: Утечка происходит, если одна или несколько горутин навсегда заблокировались на канале (или другом примитиве синхронизации), но другие горутины и программа в целом при этом продолжают работать. Утрированный пример утечки: func work() chan int { ch := make(chan int) go func() { ch <- 42 ch <- 13 // (!) утечка }() return ch } func main() { <-work() // ... } Традиционно Go не очень-то помогал в поиске утечек. Обнаружить их можн...

Go 1.26: Ускоренный cgo Слоганом Go 1.26 можно делать фразу «ускорилось ВСЕ». Помимо GreenTea GC и скоростных аллокаций (о которых я писал выше) — теперь еще и cgo-вызовы работают на 20–30% быстрее. Вот немного подробностей. В рантайме Go используются процессоры (обычно их обозначают буквой P) — это ресурсы, которые нужны для выполнения кода. Чтобы поток мог выполнять горутину, к нему должен быть привязан конкретный процессор. Процессоры могут находиться в разных состояниях: running (выполняет к...

Go 1.26: Криптография без ридеров Пожалуй, самое спорное изменение в Go 1.26. Сейчас криптографические API (например ecdsa.GenerateKey), обычно принимают io.Reader как источник случайных данных: ecdsa.GenerateKey(elliptic.P256(), rand.Reader) Эти API не гарантируют, как именно используют случайные байты из ридера. Изменение алгоритма может поменять порядок или количество читаемых байт. Поэтому приложения, которые зависят от конкретного поведения, могут перестать работать, если реализация поменяе...

map[T]struct{} В отличие от питона и джавы, в го нет «родного» типа «множество» (set). Поэтому разработчики наловчились использовать вместо него map[T]struct{}: set := make(map[string]struct{}) set["apple"] = struct{}{} if _, exists := set["apple"]; exists { fmt.Println("✓ apple") } ✓ apple Прелесть использования struct{} в том, что у такой карты значения буквально занимают 0 байт. Но в Go 1.24 пришли швейцарские карты и случился потряс устоев. map[T]struct{} теперь занимает ровно столько же пам...