Команда Go for Devs подготовила перевод отчёта команды Go о результатах Go Developer Survey 2025 (опрос проходил в сентябре 2025, публикация — 21 января 2026). Главные сигналы: разработчикам не хватает понятных best practices и более «современных» возможностей в языке и встроенных инструментах; ИИ-инструменты уже стали повседневностью, но качество и предсказуемость всё ещё подводят; а справка go по базовым подкомандам вроде go build, go run и go mod слишком часто вынуждает лезть в документацию.

Здравствуйте! В этой статье мы обсудим результаты опроса разработчиков Go за 2025 год, который проводился в сентябре 2025 года.

Спасибо 5 379 разработчикам Go, которые в этом году откликнулись на приглашение пройти опрос. Ваши ответы помогают и команде Go в Google, и более широкому сообществу Go понимать текущее состояние экосистемы Go и расставлять приоритеты на следующий год.

Три наших главных вывода:

• В целом разработчики Go просили помощи с тем, как выявлять и применять лучшие практики, лучше использовать стандартную библиотеку и развивать язык и встроенные инструменты, добавляя более современные возможности.

• Большинство разработчиков Go уже используют инструменты разработки на базе ИИ, когда ищут информацию (например, как пользоваться модулем) или занимаются рутиной (например, пишут повторяющиеся блоки похожего кода), но удовлетворённость этими инструментами средняя — в том числе из-за вопросов к качеству.

• Неожиданно большая доля участников сказала, что им часто приходится перечитывать документацию по базовым подкомандам go, включая go build, go run и go mod. Это говорит о том, что у системы справки команды go есть заметный потенциал для улучшения.

Читайте дальше — подробности по этим выводам и многое другое.

От кого мы получили ответы?

Большинство участников опроса идентифицировали себя как профессиональных разработчиков (87%), которые используют Go в основной работе (82%). При этом подавляющее большинство также применяет Go в личных или open source проектах (72%). Большинство респондентов — в возрасте 25–45 лет (68%) и имеют как минимум шесть лет профессионального опыта разработки (75%). Если копнуть глубже, 81% участников сообщили, что их профессиональный опыт разработки больше, чем опыт именно с Go — серьёзный признак того, что Go обычно не первый язык в карьере разработчика. На самом деле одна из тем, которая снова и снова всплывала в анализе этого года, вытекает именно из этого: когда способ решить задачу в Go существенно отличается от более привычного языка, у разработчиков возникает трение — сначала нужно освоить новый (для них) идиоматичный паттерн Go, а затем постоянно помнить эти отличия, продолжая параллельно работать с несколькими языками. Мы ещё вернёмся к этой теме позже.

Самая распространённая отрасль, в которой работают участники, — «Технологии» (46%), однако большинство респондентов трудится вне технологической отрасли (54%). Были представлены организации всех размеров: едва заметное большинство работает в компаниях с 2–500 сотрудниками (51%), 9% работают в одиночку, а 30% — в корпорациях более чем с 1 000 сотрудников. Как и в прошлые годы, большинство ответов пришло из Северной Америки и Европы.

В этом году мы увидели снижение доли респондентов, которые сказали, что довольно недавно начали работать с Go — меньше одного года (13% против 21% в 2024). Мы предполагаем, что это связано с общерыночным снижением количества позиций начального уровня в software engineering: мы часто слышим, что люди изучали Go под конкретную работу, поэтому спад найма закономерно должен уменьшать число разработчиков, которые изучают Go в соответствующий год. Эту гипотезу дополнительно поддерживает наблюдение, что более 80% участников изучили Go уже после начала профессиональной карьеры.

Кроме сказанного выше, заметных изменений в остальной демографии по сравнению с опросом 2024 года мы не обнаружили.

Как люди относятся к Go?

Подавляющее большинство участников (91%) сказали, что им комфортно работать с Go. Почти ⅔ выбрали вариант «очень доволен(на)» — это самая высокая оценка. Оба показателя исключительно позитивны и остаются стабильными с 2019 года, когда мы впервые начали задавать этот вопрос. Стабильность во времени — это как раз то, что мы отслеживаем в этом показателе: мы считаем его запаздывающим индикатором — то есть к тому моменту, когда этот показатель удовлетворённости заметно сдвинется, мы ожидаем, что уже увидим ранние сигналы из отчётов об issue, списков рассылки или других каналов обратной связи сообщества.

Почему ответы настолько позитивные? Анализ свободных текстовых ответов на несколько разных вопросов показывает, что дело скорее в общей картине, а не в каком-то одном факторе. Люди говорят, что видят огромную ценность в Go как в целостной платформе. Это не означает, что Go одинаково хорошо подходит для всех областей программирования (конечно, нет), но разработчики ценят те области, которые он действительно хорошо покрывает — благодаря stdlib и встроенным инструментам.

Ниже — несколько характерных цитат участников. Чтобы дать контекст, мы также указываем уровень удовлетворённости, стаж работы с Go и отрасль респондента.

«Go — безусловно мой любимый язык; другие языки кажутся слишком сложными и мало полезными. То, что Go сравнительно небольшой и простой, с меньшим количеством “наворотов”, играет огромную роль и делает его отличным долговечным фундаментом для разработки. Мне нравится, что он одинаково хорошо масштабируется — и для одного программиста, и для больших команд».

— Очень доволен(на) / 10+ лет / Технологическая компания

«Главная причина, почему я использую Go, — это отличные инструменты и стандартная библиотека. Я очень благодарен команде за фокус на отличных инструментах для HTTP, криптографии, математики, синхронизации и многого другого — это делает разработку сервисных приложений простой и надёжной».

— Очень доволен(на) / 10+ лет / Энергетика

«Экосистема Go — причина, по которой мне действительно нравится этот язык. В последнее время с npm много проблем, а с Go — нет».

— Очень доволен(на) / 3–10 лет / Финансовые услуги

В этом году мы также спросили, какими ещё языками люди пользуются. Участники опроса сказали, что помимо Go им нравится работать с Python, Rust и TypeScript, а также с длинным хвостом других языков. Некоторые общие особенности этих языков пересекаются с типичными источниками трения, о которых сообщают разработчики Go: например, обработка ошибок, enum’ы и объектно-ориентированные паттерны проектирования. Например, если суммировать доли респондентов, которые сказали, что их следующий любимый язык включает один из следующих факторов, то получится, что большинству нравятся языки с наследованием, типобезопасными enum’ами и исключениями, а вот статическая типизация «по умолчанию» встречается лишь у едва заметного большинства этих языков.

Мы считаем это важным, потому что это показывает более широкий контекст, в котором работают разработчики: получается, что для довольно рядовых задач людям приходится применять разные паттерны проектирования в зависимости от языка текущей кодовой базы. Это приводит к дополнительной когнитивной нагрузке и путанице — не только у новичков в Go (которым нужно изучить идиоматичные паттерны Go), но и у множества разработчиков, которые работают сразу в нескольких кодовых базах или проектах. Один из способов снизить эту нагрузку — контекстные рекомендации, например туториал «Обработка ошибок в Go для Java-разработчиков». Возможно, часть таких подсказок можно встроить в анализаторы кода, чтобы показывать их прямо в IDE.

В этом году мы попросили сообщество Go поделиться отношением к самому проекту Go. Эти результаты заметно отличались от 91% удовлетворённости, о которой мы говорили выше, и указывают на направления, куда команда Go планирует вкладывать энергию в 2026 году. В частности, мы хотим вовлечь больше участников в контрибьютинг и убедиться, что команда Go корректно понимает сложности, с которыми сейчас сталкиваются разработчики Go. Мы надеемся, что этот фокус, в свою очередь, поможет повысить доверие разработчиков и к проекту Go, и к руководству команды Go. Как объяснил один из респондентов:

«Теперь, когда основатели — первое поколение участников команды Go — уже не так вовлечены в принятие решений, я немного переживаю за будущее Go с точки зрения качества сопровождения и той взвешенности решений, которая была до сих пор — особенно в том, что касается изменений в языке и std lib. Больше присутствия в виде докладов новых участников core-команды о текущем состоянии и планах может помочь укрепить доверие».

— Очень доволен(на) / 10+ лет / Технологическая компания

Что люди создают на Go?

Мы переработали список «что вы создаёте на Go?» по сравнению с 2024 годом, чтобы полезнее разложить по полочкам, что именно люди делают на Go, и избежать путаницы вокруг меняющихся терминов вроде «агенты». Топовые сценарии у респондентов — по-прежнему CLI и API-сервисы, без существенных изменений относительно 2024 года. Более того, большинство участников (55%) сказали, что на Go делают и CLI, и API-сервисы. Более ⅓ участников отдельно указали, что создают инструменты для облачной инфраструктуры (новая категория), а 11% работают с ML-моделями, инструментами или агентами (расширенная категория). К сожалению, варианты для embedded-сценариев не попали в обновлённый список — мы исправим это в опросе следующего года.

Большинство участников сказали, что сейчас не добавляют ИИ-фичи в Go-ПО, над которым работают (78%); при этом ⅔ сообщили, что их софт вообще не использует ИИ-возможности (66%). Похоже, что по сравнению с прошлым годом это снижение использования ИИ в продакшене: в 2024 году 59% участников не были вовлечены в работу над ИИ-фичами, а 39% указывали некоторый уровень вовлечённости. Это сдвиг на 14 пунктов в сторону меньшей доли разработчиков, которые стр��ят ИИ-системы, и, возможно, отражает естественный откат после раннего ажиотажа вокруг ИИ-приложений: вероятно, многие попробовали, что можно сделать с технологией на старте, а часть затем решила не продолжать эксперименты (по крайней мере сейчас).

Среди тех, кто создаёт функциональность на базе ИИ или LLM, самым распространённым сценарием было создание кратких резюме существующего контента (45%). В целом, однако, по большинству применений разница была небольшой: от 28% до 33% респондентов добавляют ИИ-функциональность для классификации, генерации, поиска решений, чат-ботов и разработки ПО.

Какие самые большие сложности стоят перед разработчиками Go?

Один из самых полезных типов обратной связи, который мы получаем, — это подробности о сложностях, с которыми люди сталкиваются, работая с Go. Команда Go рассматривает эту информацию целостно и на длинных горизонтах, потому что часто есть напряжение между тем, чтобы сгладить шероховатости Go, и тем, чтобы сохранять язык и инструменты последовательными для разработчиков. Помимо чисто технических факторов, каждое изменение также имеет цену — в виде внимания разработчиков и когнитивных «переключений». Минимизация подобных сбоев может звучать скучно, но мы считаем это важной сильной стороной Go. Как писал Расс Кокс в 2023 году: «Скучно — это хорошо… Скучно означает, что можно сосредоточиться на своей работе, а не на том, чем Go отличается».

В этом духе главные сложности этого года не радикально отличаются от прошлого. Три главных раздражителя, о которых сообщили участники: «Следить, чтобы наш Go-код соответствовал лучшим практикам / идиомам Go» (33%), «В Go нет возможности, которую я ценю в другом языке» (28%), и «Находить надёжные Go-модули и пакеты» (26%). Мы изучили свободные текстовые ответы, чтобы лучше понять, что именно имеют в виду люди. Давайте на минуту разберём каждый пункт.

Те, кого больше всего раздражает написание идиоматичного Go, часто хотят больше официальных рекомендаций, а также поддержки со стороны инструментов, чтобы проще было закреплять эти рекомендации в кодовой базе. Как и в прошлых опросах, вопросы о том, как структурировать Go-проекты, тоже были частой темой. Например:

«Простота Go помогает читать и понимать код других разработчиков, но всё равно есть > аспекты, которые могут сильно различаться от программиста к программисту. Особенно если люди приходят из других языков, например Java».

— Очень доволен(на) / 3–10 лет / Медицина и бионауки

«Более “направляющий” подход к написанию Go-кода. Например, как структурировать Go-проект для сервисов/cli tool».

— Очень доволен(на) / < 3 лет / Технологии

«Трудно понять, какие идиомы хорошие. Особенно потому, что core-команда не поддерживает Effective Go в актуальном состоянии».

— Очень доволен(на) / 3–10 лет / Технологии

Вторая крупная категория раздражителей — возможности языка, к которым разработчики привыкли в других экосистемах. Эти комментарии в основном касались паттернов обработки и представления ошибок, enum’ов и sum types, безопасности nil-указателей, а также общей выразительности / многословности:

«До сих пор не уверен, какой лучший способ обрабатывать ошибки».

— Очень доволен(на) / 3–10 лет / Ритейл и потребительские товары

«Enum’ы в Rust отличные и приводят к написанию действительно хорошего типобезопасного кода».

— Скорее доволен(на) / 3–10 лет / Медицина и бионауки

«Ничто (в компиляторе) не мешает мне использовать возможно nil-указатель или использовать значение, не проверив сначала err. Это должно быть [встроено] в систему типов».

— Скорее доволен(на) / < 3 лет / Технологии

«Мне нравится [Go], но я не ожидал, что в нём будут nil pointer exceptions :)»

— Скорее доволен(на) / 3–10 лет / Финансовые услуги

«Мне часто трудно строить абстракции и ясно передавать намерения будущим читателям моего кода».

— Скорее недоволен(на) / < 3 лет / Технологии

Третий крупный источник раздражения — поиск надёжных Go-модулей. Респонденты часто описывали здесь два аспекта проблемы. Первый — многие сторонние модули, по их мнению, имеют пограничное качество, из-за чего действительно хорошие решения теряются на фоне остальных. Второй — сложно понять, какие модули широко используются и в каких условиях (включая изменения трендов со временем). Обе проблемы можно было бы решать, показывая на pkg.go.dev то, что мы в общем виде назовём «сигналами качества». Участники хорошо объяснили, какие сигналы они используют, чтобы определить надёжность модуля: активность проекта, качество кода, недавние тренды принятия, или какие именно организации поддерживают модуль или зависят от него.

«Возможность фильтровать по критериям вроде стабильной версии, числа пользователей и давности последнего обновления на pkg.go.dev могла бы немного упростить жизнь».

— Очень доволен(на) / < 3 лет / Технологии

«Многие pacakges — просто клоны/форки или разовые pojects без истории/сопровождения.»

— Очень доволен(на) / 10+ лет / Финансовые услуги

«Может быть, отмечать надёжные пакеты на основе опыта, зрелости и отзывов сообщества?»

— Очень доволен(на) / 3–10 лет / Медицина и бионауки

Мы согласны: во всех этих областях опыт разработки с Go можно улучшить. Сложность, как обсуждалось выше, в том, чтобы сделать это так, чтобы не привести к ломающим изменениям, не увеличить путаницу среди разработчиков Go и вообще не мешать людям делать свою работу на Go. Обратная связь из этого опроса — один из ключевых источников информации, который мы используем при обсуждении предложений, но если вы хотите подключиться более напрямую или просто следить за процессом вместе с другими контрибьюторами, загляните в раздел предложений Go на GitHub; пожалуйста, следуйте этому процессу, если хотите добавить новое предложение.

В дополнение к этим (потенциально) экосистемным проблемам, в этом году мы отдельно спросили о работе с командой go. Мы неформально слышали от разработчиков, что в системе справки этого инструмента бывает трудно ориентироваться, но у нас не было хорошего понимания, как часто людям приходится возвращаться к этой документации.

Участники сказали, что, кроме go test, у 15–25% из них «часто возникает необходимость пересматривать документацию» при работе с этими инструментами. Это было неожиданно — особенно для часто используемых подкоманд вроде build и run. Среди типичных причин называли необходимость помнить конкретные флаги, понимать, что делают разные параметры, и разбираться в самой системе справки. Участники также подтвердили, что редкое использование — один из факторов раздражения, но, похоже, первопричина — в навигации и чтении справки команды. Иными словами, всем приходится иногда перечитывать документацию, но мы не ожидаем, что потребуется помощь, чтобы ориентироваться в самой системе документации. Как описал один респондент свой путь:

«Доступ к справке мучительный. go test –help # не сработало, но говорит набрать go help test… go help test # о, вообще-то нужная мне информация в testflag go help testflag # визуально разбирать текст, который выглядит одинаково и почти без форматирования… у меня просто нет времени нырять в эту кроличью нору». — Очень доволен(на) / 10+ лет / Технологии

Как выглядят их dev-окружение?

Операционные системы и архитектуры

В целом участники сообщили, что их платформы разработки — UNIX-подобные. Большинство разрабатывает на macOS (60%) или Linux (58%) и развёртывает на системах на базе Linux, включая контейнеры (96%). Самое заметное изменение год к году — по развёртываниям на «embedded-устройства / IoT»: доля выросла с 2% до 8%; это было единственным существенным изменением в платформах развёртывания с 2024 года.

Подавляющее большинство разрабатывает под архитектуры x86-64 или ARM64, при этом заметная группа (25%), возможно, всё ещё работает на 32-битных x86-системах. Однако мы считаем, что формулировка вопроса сбила респондентов с толку; в следующем году мы уточним различие между 32-бит и 64-бит для каждой архитектуры.

Редакторы кода

За последние два года появилось несколько новых редакторов, и мы расширили вопрос в опросе, чтобы включить самые популярные. Хотя мы увидели некоторые признаки раннего принятия, большинство участников по-прежнему предпочитает VS Code (37%) или GoLand (28%). Среди более новых редакторов наивысшие позиции заняли Zed и Cursor — каждый стал предпочтительным редактором у 4% респондентов. Чтобы понять масштаб, мы посмотрели, как было на старте у VS Code и GoLand. VS Code (выпущен в 2015) через год после релиза предпочитали 16% респондентов. IntelliJ имел Go-плагин, поддерживаемый сообществом, ещё до того, как мы начали проводить опросы среди Go-разработчиков (💙), но если посмотреть на момент, когда JetBrains начал официально поддерживать Go в IntelliJ (2016), то уже через год IntelliJ предпочитали 20% респондентов.

Примечание: этот анализ редакторов не включает респондентов, которые попали на опрос по прямой ссылке из VS Code или GoLand.

Облачные окружения

Самые распространённые окружения развёртывания для Go остаются прежними: Amazon Web Services (AWS) — у 46% респондентов, серверы компании — у 44%, и Google Cloud Platform (GCP) — у 26%. По сравнению с 2024 годом это небольшие сдвиги, но статистически незначимые. Мы заметили, что категория «Другое» выросла до 11% в этом году, и главным образом это произошло из-за Hetzner (20% ответов внутри «Другое»); в следующем году мы планируем добавить Hetzner как отдельный вариант ответа.

Мы также спросили о том, как респонденты оценивают опыт разработки с разными облачными провайдерами. Однако самые частые ответы показывали, что участники либо не очень уверены (46%), либо вообще не взаимодействуют напрямую с публичными облачными провайдерами (21%). Основной драйвер этого — тема, которую мы слышали и раньше: с контейнерами можно абстрагировать от разработчика множество деталей облачной среды, так что он почти не взаимодействует с провайдер-специфичными технологиями. Этот результат подсказывает, что даже разработчики, чей код развёрнут в облаках, могут иметь ограниченный опыт работы со всем набором инструментов и технологий конкретного провайдера. Например:

«Платформа в целом абстрагирована: Go очень легко упаковать в контейнер и поэтому довольно легко развернуть где угодно — одна из его больших сильных сторон».

— [нет ответа про удовлетворённость] / 3–10 лет / Технологии

«Облачный провайдер для меня почти не имеет значения. Я пишу код и развёртываю его в контейнеры, так что AWS это или GCP — мне всё равно».

— Скорее доволен(на) / 3–10 лет / Финансовые услуги

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

Разработка с ИИ

Наконец, говоря об окружении разработчиков в 2025 году, нельзя не упомянуть инструменты разработки на базе ИИ. Наш опрос показывает «раздвоенное» принятие: хотя большинство участников (53%) сказали, что пользуются такими инструментами ежедневно, есть и крупная группа (29%), которая вообще ими не пользуется или использовала их всего несколько раз за последний месяц. Мы ожидали, что это будет отрицательно коррелировать с возрастом или опытом разработки, но не смогли найти сильных доказательств этой гипотезе — кроме совсем новых разработчиков: респонденты с опытом профессиональной разработки менее одного года (не обязательно в Go) действительно сообщали о более активном использовании ИИ, чем все остальные когорты, но эта группа составила лишь 2% участников.

На данный момент «агентное» использование инструментов на базе ИИ среди разработчиков Go выглядит ранним: лишь 17% сказали, что это их основной способ использования таких инструментов, хотя более крупная группа (40%) иногда пробует агентные режимы.

Самые часто используемые ИИ-ассистенты остаются теми же: ChatGPT, GitHub Copilot и Claude. У большинства из этих инструментов показатели использования ниже, чем в опросе 2024 года (Claude и Cursor — заметные исключения), но из-за изменения методологии это нельзя сравнивать напрямую. Тем не менее, вполне возможно, что разработчики стали меньше «пробовать всё подряд», чем в первые месяцы появления этих инструментов, и всё больше людей выбирают одного ассистента для основной части задач.

Мы также спросили об общей удовлетворённости инструментами разработки на базе ИИ. Большинство (55%) сказали, что довольны, но это сильно смещено в сторону категории «скорее доволен(на)» (42%) по сравнению с «очень доволен(на)» (13%). Напомним, сам Go ежегодно стабильно показывает 90%+ удовлетворённости; в этом году 62% респондентов сказали, что «очень довольны» Go. Мы приводим этот контекст, чтобы показать: хотя инструменты на базе ИИ начинают внедряться и находят успешные сценарии, отношение к ним у разработчиков остаётся заметно более сдержанным, чем к устоявшимся инструментам (по крайней мере среди Go-разработчиков).

Что же приводит к такой более низкой удовлетворённости? Одним словом — качество. Мы попросили участников рассказать, что хорошего они сделали с помощью этих инструментов и что у них не получилось. Большинство сказали, что главная проблема ИИ-инструментов для разработчиков — генерация неработающего кода (53%), а 30% посетовали, что даже рабочий код получается низкого качества. Наиболее часто упоминаемые выгоды, наоборот, — генерация unit-тестов, написание шаблонного кода, улучшенный автокомплит, рефакторинг и генерация документации. Похоже, это как раз те случаи, где качество кода воспринимается как менее критичное, и баланс склоняется в пользу того, чтобы позволить ИИ сделать первый проход по задаче. При этом респонденты также говорили, что даже в успешных сценариях ИИ-код всё равно нужно тщательно проверять (и часто править), потому что он может быть с багами, небезопасным или не учитывать контекст.

«Я никогда не доволен качеством или единообразием кода — он никогда не следует тем практикам, которые мне нужны».

— [нет ответа про удовлетворённость] / 3–10 лет / Финансовые услуги

«Все ИИ-инструменты быстро начинают “галлюцинировать”, когда работаешь со средними и большими кодовыми базами (10k+ строк кода). Они могут хорошо объяснять код, но им сложно генерировать новые сложные возможности»

— Скорее доволен(на) / 3–10 лет / Ритейл и потребительские товары

«Несмотря на многочисленные попытки заставить его писать код в существующей кодовой базе, слишком много усилий уходит на то, чтобы направлять его следовать практикам проекта, а ещё он добавляет тонкие пути поведения — то есть если он пропустит какой-то метод, он попробует “обойти” это или опереться на побочный эффект. Иногда такие вещи трудно заметить во время code review. Я также обнаружил, что мне психологически тяжело проверять код, сгенерированный ИИ, и этот накладной расход убивает потенциальный прирост производительности от написания кода».

— Очень доволен(на) / 10+ лет / Технологии

Когда мы спросили разработчиков, для чего они используют эти инструменты, проявился паттерн, согласующийся с описанными проблемами качества. Задачи с наибольшим принятием (зелёным на диаграмме ниже) и наименьшим сопротивлением (красным) связаны с закрытием пробелов в знаниях, улучшением локального кода и избавлением от рутины. Раздражение, о котором разработчики говорят применительно к инструментам генерации кода, было куда менее заметно, когда они ищут информацию — например, как использовать конкретный API или настроить покрытие тестами, — и, возможно, поэтому мы видим более высокое использование ИИ в этих областях. Ещё одна выделяющаяся область — локальный code review и связанные с ним подсказки: людям интереснее использовать ИИ для ревью собственного кода, чем для ревью чужого. Неожиданно «тестовый код» показал более низкое принятие ИИ, чем другие рутинные задачи, хотя у нас пока нет уверенного понимания причин.

Из всех задач, о которых мы спрашивали, «написание кода» оказалось самым «раздвоенным»: 66% респондентов уже используют ИИ для этого или надеются начать в ближайшее время, тогда как ¼ участников не хотят вовлекать ИИ вообще. Свободные ответы показывают, что разработчики в основном используют это для рутинного, повторяющегося кода и по-прежнему переживают из-за качества ИИ-генерации.

Заключение

Ещё раз — огромное спасибо всем, кто ответил на вопросы опроса разработчиков Go этого года!

Мы планируем опубликовать «сырые» данные опроса в Q1 2026, чтобы сообщество тоже могло изучить данные, лежащие в основе этих выводов. Туда войдут только ответы тех, кто согласился поделиться данными (82% всех респондентов), поэтому цифры могут немного отличаться от тех, на которые мы ссылаемся в этой статье.

Русскоязычное Go сообщество

Друзья! Эту статью подготовила команда «Go for Devs» — сообщества, где мы делимся практическими кейсами, инструментами для разработчиков и свежими новостями из мира Go. Подписывайтесь, чтобы быть в курсе и ничего не упустить!