Comments 31
Ожидание: программы на го станут быстрее, сохраняя безопасное управлению памятью в бОльшей части кодовой базы
Реальность: программы на го текут пуще прежнего, тонны новых use-after-free/buffer overruns
/s
Ладно утечки... Лично меня больше напрягают битые ссылки, которые выявляются только при запуске со специальными флагами...
А там и гонки - что быстрее? Переменная прочтется или перезапишется?
ооо, гонок в голанге и без арен хватает :) ref/mem написан кровью программистов
битые ссылки
В смысле nil-указатели? Так используйте меньше указателей. Часто вижу []*Object и прочее таскание указателей по всем функциям, из-за чего страдает и программист, и GC)
По части nil-указателей у меня лишь болит от использования неинициализированной map'ы. Так легко объявить и так легко забыть инициализировать)
Битые ссылки - это не nil-указатели, а указатель на область памяти, где раньше была эта переменная, а потом ее собрал сборщик мусора и пометил область свободной для заполнения снова...
В итоге к моменту чтения, по старому адресу уже совсем другие данные могут оказаться...
Проблема в том, что возникает плавающая бага, которую очень сложно диагностировать (в любом языке)...
программы на го текут пуще прежнего
А что именно текло: приложения или библиотека? У меня Go-приложения текли только когда неправильно использовался unsafe)
Течет не напрямую память (хотя и с ней до того, как начали использовать MADV_FREE были приколы), а горутины, которые тем или иным способом не умирают и коптят на каком-нибудь канале до самой смерти процесса, вместе со всеми своими ресурсами
Могут довольно интересно течь.
Например через горутины, которые не завершаются.
Ещё если у вас есть массивы и вы их переиспользуете, то у них capacity не меняется, а меняется только длина, соответственно, в памяти такой массив будет занимать много места, т.к. лишние элементы просто скрыты между len и cap и GC их не будет удалять.
Одной из революционных особенностей Go в сравнении с другими компилируемыми языками стало автоматическое управление освобождением памяти от неиспользуемых объектов
Вы это серьёзно? Языки с GC были задолго до go
Хабр захватили переводчики на окладе :(
ключевое слово - компилируемыми. Приведёте пример языка, который генерит самодостаточный экзэшник с GC внутри?
Конечно: Standart ML/OCaml, Haskell, Eiffel, да даже в Ada была ограниченная сборка мусора. Rust, кстати, тоже раньше go начали разрабатывать
А причем компиляция и самодостаточность екзешника?
Java и C# вполне компилируются, пускай и в промежуточное представление.
К слову, дотнет может собираться в единый исполняемый файл с рантаймом внутри.
А в новой версии .NET c ограничениями, но можно даже сразу в машинный код
Джава компилируемый язык, там гц. И ещё миллиард языков. Хаскель также компилируемый с гц.
Это не то что не революция, это даунгрейд.
А приведённый "отличный новый код" это просто ужас, код на С и то лучше чем на go.
Дизайнеры go буквально сделали сишку с сборкой мусора и без единого плюса сишки
Мне кажется или это превращает го в си?
Революционные костыли
Подскажите пожалуйста: если всю динамическую память выделяем через arena, то сборщик мусора тогда вообще не запускается?
В теории, да. Чтобы наверняка, можно установить GOGC=off
Есть подозрения, что именно так и сделают в tinygo. А вообще, довольно странный ход. Видимо, в следующей итерации добавят возможно писать и выбирать аллокаторы памяти и будет почти C, только больше кода, почти C++, только меньше возможностей. Для меня было бы киллер-фичей возможность запускать горутины при помощи аллокатора и убивать их при необходимости.
Go 1.20 и арена памяти