Go отказался от экспериментальных Memory Arenas - механизма, позволявшего выделять память крупными пулами в обход GC для снижения накладных расходов в высоконагруженных сценариях.
Автор считает это стратегической ошибкой. Формальной причиной стали проблемы безопасности, когда можно попытаться использовать память после ее освобождения. И еще никому не понравилась несовместимость с интерфейсами - пришлось бы добавлять аргумент *Arena в сигнатуры функций, и это раскололо бы экосистему на стандартный и arena-миры, подобно тому как context.Context когда-то "инфицировал" весь Go.
Но, по мнению автора, реальная опасность в том, что Go добровольно ограничил свой потолок производительности в момент, когда быстрые интерпретируемые языки догоняют его сверху, а системные языки вроде Rust и Zig становятся проще снизу. Go рискует остаться застывшим в "среднем" сегменте, став COBOLом облачной эпохи
28.07.2026
Похожее
28.09.2026
C на Go
Интересный пропозал - добавить возможность сборки Go-пакетов, использующих cgo д...
25.09.2026
Бенчим джейсон
Автор на реальном API с нагрузкой 50M запросов/сутки)сравнивает производительнос...
24.09.2026
Rune
Команда Unstable Build заопенсорсила свою нативную IDE Rune, написанную на Go. ...
23.09.2026
Специализированные аллокаторы
В Go 1.27 появилась оптимизация выделения памяти для объектов размером до 80 бай...