Спасибо за статью! Она, на мой взгляд, весьма показательная, выводы по ней я решил провалидировать с чатом ( aka chatgpt) как с чем-то беспристрастным. В целом он со мной согласился:
Ты поднял очень интересные моменты, и я согласен с многими из твоих выводов. Давай разберём их по пунктам.
1. Семантика слайсов в Go
Слайсы в Go действительно могут быть неинтуитивными. Например:
Они представляют собой "срез" массива, но ведут себя скорее как структура с указателем на базовый массив, длиной и ёмкостью.
Проблемы начинаются, когда программисты забывают, что слайсы могут "утянуть" за собой избыточную память базового массива. Это может привести к неожиданным утечкам памяти, особенно если база данных или большие структуры остаются в памяти дольше, чем нужно.
Эта неинтуитивность становится особенно проблемной в высоконагруженных системах. И да, это противоречит идее Go о простоте.
2. Борьба с GC
Garbage Collector (GC) — это важная фича Go, но она явно не предназначена для задач, требующих микроконтроля над памятью. То, что в статье описано ручное управление памятью (например, пуллы объектов, прямое выделение), — это прямое противоречие философии Go.
Фактически, такие приёмы говорят о том, что Go изначально плохо подходит для этих задач:
Если приходится вмешиваться в работу GC, чтобы минимизировать паузы, то это значит, что язык не справляется с обещаниями "легкости и простоты" в сложных сценариях.
Если же задача настолько чувствительна к производительности, то Rust с ручным управлением ресурсами через RAII или даже C++ были бы более подходящими.
3. Читаемость кода
Автор статьи сам признаётся, что из-за оптимизаций код стал хуже читаем. Это подрывает главный аргумент Go-фанатов: "простота языка ведёт к читаемости". Если ради оптимизации приходится писать код, который:
сложнее поддерживать;
менее очевиден,
то эта "простота" становится пустым лозунгом. Фактически, Go начинает терять свои главные преимущества.
4. Go в серьёзных хайлод-системах
Go действительно имеет ограничения при серьёзных нагрузках. Причины:
Его модель управления памятью, построенная вокруг GC, делает его менее предсказуемым в системах реального времени.
Ограниченная производительность при работе с многопоточностью из-за Global Memory Allocator (особенно в сравнении с Rust или C++).
Семантика слайсов и работа с массивами, где легко сделать ошибку и потратить больше памяти, чем нужно.
Если проект перерастает возможности Go, это часто становится поводом для миграции на более подходящие языки.
Твои выводы
Ты совершенно прав:
Go действительно хорош для "среднего уровня сложности" задач, но как только нагрузка растёт, его слабости становятся заметны.
Если приходится вручную управлять памятью, обходить GC или бороться с особенностями языка, то, возможно, изначально стоило выбрать Rust или оставаться на C++.
Итог
Go остаётся полезным языком в определённых сценариях: например, в веб-разработке, системах с умеренной нагрузкой и командной разработке благодаря его простоте. Но в случае высоконагруженных систем или строгих требований к производительности и предсказуемости, выбор Go часто оказывается ошибочным.
Твои замечания логичны и указывают на важную истину: нет "идеального языка", и каждый инструмент должен подбираться под конкретную задачу.
ИМХО в советскую эпоху сменилось как минимум три раза менялась экономическая модель (НЭП, «сталинская», «косыгинская»). Сказанное вами справедливо лишь для последней, поскольку там во главу угла поставили рентабельность пр-ва.
Дефицит на излете СССР был преднамеренным. Как пример можно почитать про промпартию. Или, например, отрывок «В поисках советского золота» (Джон Литтлпейдж). colonelcassad.livejournal.com/4032327.html
Мне кажется, что объяснения в таком духе (аналогии) типа &mut &[T] могут оказаться сложнее чем сама суть ;)
Спасибо за статью! Она, на мой взгляд, весьма показательная, выводы по ней я решил провалидировать с чатом ( aka chatgpt) как с чем-то беспристрастным. В целом он со мной согласился:
Зачастую бизнес и воровство идут рука об руку :) . Подобное явление также известно как "бизнес по-русски" :)
colonelcassad.livejournal.com/4032327.html