Прочитал инересную статью «Go сделали скучным — и после нейросетей это выстрелило» https://habr.com/ru/companies/h3llo_cloud/articles/1085160/

Главная мысль: простота Go помогает писать и проверять код с LLM. Но обсуждение показывает: понятный синтаксис ещё не гарантирует понятную систему.

5 тезисов статьи

1. Простота — осознанный выбор. Авторы Go ограничивали сложность языка ради читаемости и удобства разработки. Матрёничев считает, что эти свойства полезны и при генерации кода.

2. Дженерики требуют компромиссов. Их долгое отсутствие объясняется поиском подходящего решения: обобщения должны сочетаться с быстрой компиляцией, приемлемыми затратами памяти и остальной системой типов.

3. Совместимость создаёт обязательства. Стабильность позволяет использовать старый код, но ограничивает изменения языка. Даже доступ к некоторым внутренним функциям пришлось сохранить из-за зависимых библиотек — отсюда hall of shame в исходниках.

4. AI-инфраструктура продолжает облачную нишу Go. Собеседник выделяет агентов и шлюзы: простой процесс сборки, исполняемый файл и зрелая сетевая экосистема делают язык удобным для такой обвязки.

5. За результат отвечает человек. Использовать AI допустимо, но отправляющий код разработчик должен понимать его поведение, объяснять решения и отвечать за качество. Ссылка на модель эту обязанность не снимает.

Несколько интересных комментариев

1. Dhwtj: понятные функции не равны понятной бизнес-логике. По его наблюдению, отдельные фрагменты Go читаются легко, а доменная логика может разрастаться и распределяться по разным частям приложения.

2. Jubilus: структура нужна и нейросетям. В ответ на прогноз об исчезновении «чистого кода» он напоминает: структура помогает локализовать ошибки и ограничить контекст изменений. По его мнению, длинный неструктурированный код затрудняет работу и моделей.

3. bolk: превосходство Go для LLM не очевидно. Он оспаривает центральный тезис статьи: в его опыте модели охотно выбирают Python и успешно пишут на нём. Это контрпример из практики, а не сравнительный бенчмарк.

4. vovkats: выбор языка определяется темпом продукта. Для своего приложения он выбрал Go и Wails ради быстрых изменений и проверки гипотез. Заодно поправил статью: интерфейс Wails отображается через WebView.

5. UFO_01: совместимость исходников — только часть проблемы. Он обращает внимание на системы сборки C/C++: старый код может сохранять корректность, пока инструменты и конфигурации уже требуют переделки.

Общий вывод — оценивать весь цикл разработки. При выборе языка для работы с AI полезно сравнить на своей задаче генерацию, сборку, проверку и последующие изменения. Быстро получить код — лишь один из этапов.