The Go Blog

Конференция участников 2019 года

Carmen Andoh и участники
15 августа 2019

Введение

В третий год подряд команда Go и участники собрались за день до GopherCon для обсуждения и планирования будущего проекта Go. Событие включало в себя саморганизацию в рабочие группы, обсуждение в стиле town-hall по процессу принятия предложений утром, и обсуждения на темы, выбранные участниками, в послеобеденное время. Мы попросили пяти участников написать о своем опыте в различных обсуждениях на этой конференции.

(Фото Стива Франсии.)

Компилятор и среда выполнения (отчет от Линн Боджер)

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

День начался с времени, отведённого для знакомства всех присутствующих. Было хорошее сочетание основной команды Go и других, активно участвующих в разработке Go. После этого мы решили, какие темы представляют интерес и как разделить большую группу на более мелкие. Мой интерес касается компилятора, поэтому я присоединился к этой группе и оставался с ними большую часть времени.

На нашем первом собрании было поднято множество тем, и в результате группа компилятора решила продолжать встречаться на протяжении всего дня. У меня было несколько интересных тем, которые я поделился, и многие темы, предложенные другими, также представляли интерес для меня. Не все пункты из списка были рассмотрены подробно; вот мой список тех тем, которые вызвали наибольший интерес и обсуждение, с последующими краткими комментариями по другим темам.

Размер бинарных файлов. Было выражено беспокойство по поводу размера бинарных файлов, особенно то, что он продолжает расти с каждой версией. Были выявлены некоторые возможные причины, такие как увеличение инлайнинга и другие оптимизации. Скорее всего, существует группа пользователей, желающих получить маленькие бинарники, и другая группа, которая хочет лучшей производительности и, возможно, для некоторых всё равно.

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

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

Для большинства целевых платформ существуют критически важные функции в стандартных пакетах, таких как crypto, hash, math и других, где использование ассемблера необходимо, чтобы достичь наилучшей возможной производительности; однако наличие больших функций, написанных на ассемблере, делает их сложными для поддержки и сопровождения, а также может потребовать различных реализаций для каждой целевой платформы. Одно из решений — использовать макроассемблер или другие высокоуровневые техники генерации, чтобы сделать векторный ассемблер более читаемым и понятным.

Другой аспект этого вопроса заключается в том, может ли компилятор Go напрямую генерировать SIMD-векторные инструкции при компиляции исходного файла Go, путем расширения компилятора Go для преобразования последовательностей кода в «simdize» с целью использования векторных инструкций. Реализация SIMD в компиляторе Go добавила бы сложность и увеличила бы время компиляции, и это не всегда привело бы к более производительному коду. Способ преобразования кода в некоторых случаях может зависеть от целевой платформы, что также не является идеальным.

Еще один способ использования векторных инструкций в Go — предоставить возможность более простого использования векторных инструкций непосредственно из исходного кода Go. Обсуждались темы, такие как интринсиксы или реализации, существующие в других компиляторах, например, в Rust. В GCC некоторые платформы предоставляют встроенный ассемблер (inline asm), и Go также могла бы обеспечить эту возможность, но я знаю из личного опыта, что смешивание встроенного ассемблера с кодом Go добавляет сложность компилятору в плане отслеживания использования регистров и отладки. Это позволяет пользователю делать вещи, что компилятор может не ожидать или не желать, и добавляет дополнительный уровень сложности. Вставка такого кода может происходить в неидеальных местах.

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

Новый вызов функций. Несколько человек проявили интерес к теме изменений ABI для предоставления вызова функций через регистры. Был предоставлен текущий статус с подробностями. Обсуждалось, что еще нужно сделать, чтобы можно было использовать этот механизм. Сначала необходимо написать спецификацию ABI, и неясно, когда это будет сделано. Я знаю, что это будет полезно для некоторых целевых платформ больше, чем для других, и соглашение о вызовах через регистры используется в большинстве компиляторов для других платформ.

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

Оптимизации, основанные на обратной связи. Это обсуждалось и обсуждалось как возможное будущее улучшение. По моему опыту, трудно найти осмысленные программы для сбора данных о производительности, которые затем можно использовать для оптимизации кода. Это увеличивает время компиляции и требует много места для хранения данных, которые могут быть значимы только для небольшого набора программ.

Ожидающие заявки. Несколько участников группы упомянули изменения, над которыми они работали и планируют отправить в ближайшее время, включая улучшения в makeslice и переписывание rulegen.

Проблемы времени компиляции. Время компиляции было кратко рассмотрено. Было отмечено, что время фаз было добавлено в вывод GOSSAFUNC.

Связь участников компилятора. Кто-то спросил, нужен ли список рассылки для компилятора Go. Предлагалось использовать golang-dev для этой цели, добавляя compiler в тему письма, чтобы идентифицировать его. Если на golang-dev станет слишком много трафика, тогда можно рассмотреть создание специализированной рассылки для компилятора в более позднее время.

Сообщество. Я нашел этот день очень полезным в плане взаимодействия с людьми, которые активно участвуют в сообществе и имеют схожие интересы. Мне удалось встретить многих людей, которых я знал только по их пользовательским именам, появляющимся в вопросах, списках рассылки или CLs. Мне удалось обсудить некоторые темы и существующие проблемы и получить прямую интерактивную обратную связь вместо ожидания онлайн-ответов. Меня поощрили написать задачи по проблемам, которые я наблюдал. Эти связи возникли не только в течение этого дня, но и во время встреч с другими участниками в течение конференции, после того как они были представлены в первый день, что привело к множеству интересных обсуждений. Надеюсь, эти связи приведут к более эффективной коммуникации и улучшенному управлению проблемами и изменениями кода в будущем.

Инструменты (отчет от Пола Джолли)

Сессия по инструментам во время саммита участников проходила в расширенном формате, с двумя дополнительными сессиями в основные дни конференции, организованными группой golang-tools. Этот обзор разбит на две части: сессия по инструментам на саммите участников и объединенный отчет от сессий golang-tools в основные дни конференции.

Саммит участников. Сессия по инструментам началась с представлений около 25 человек, собравшихся, за которым последовало мозговой штурм по темам, включая: gopls, ARM 32-бит, eval, сигнал, анализ, go/packages api, рефакторинг, pprof, опыт работы с модулями, анализ в монорепозитории, go mobile, зависимости, интеграции редакторов, решения по оптимизациям компилятора, отладка, визуализация, документация. Много людей с большим интересом к большим количеству инструментов!

Сессия сосредоточилась на двух областях (все, что позволило время): gopls и визуализация. Gopls (произносится как: “go please”) — это реализация Протокола сервера языка (LSP) для Go. Ребекка Стамблер, главный автор gopls, и остальная команда инструментов Go были заинтересованы в том, чтобы услышать отзывы людей о работе с gopls: стабильность, отсутствующие функции, интеграции в редакторы и т. д.? Общее впечатление было в том, что gopls находится в очень хорошем состоянии и отлично работает для большинства случаев использования. Необходимо улучшить покрытие тестами интеграции, но это сложная задача, чтобы сделать правильно во всех редакторах. Мы обсуждали лучший способ для пользователей сообщать об ошибках gopls, которые они сталкиваются через свой редактор, телеметрия/диагностика, метрики производительности gopls — все эти темы получили более подробное рассмотрение в сессиях golang-tools, проходивших в основные дни конференции (см. ниже). Ключевой областью обсуждения было, как расширить gopls, например, в форме дополнительных проверок, подобных go/analysis vet, проверок линтера, рефакторинга и т. д. В настоящее время нет хорошего решения, но активно изучается. Разговор перешел к очень широкой теме визуализаций, с демонстрацией от Антони Старкса (кстати, он дал отличную лекцию о Go для информационных дисплеев на GopherCon 2018).

Дни конференции. Сессии по golang-tools в дни основной конференции стали продолжением месячных звонков, которые проходят с момента основания группы на GopherCon 2018. Полные заметки доступны для сессий дня 1 и дня 2. Эти сессии снова были хорошо посещаемы, в каждой из них присутствовало около 25–30 человек. Команда инструментов Go присутствовала в полной мере (что является хорошим знаком поддержки, оказываемой в этой области), как и команда платформы Uber. В отличие от конференции для участников, целью этих сессий было получить конкретные задачи для реализации.

Gopls. «Готовность» gopls была основной темой обеих сессий. Ответ в основном сводился к определению момента, когда имеет смысл сообщать разработчикам редакторов: «у нас есть первая версия gopls», а затем составить список «одобренных» интеграций/плагинов редакторов, известных как работающих с gopls. Центральным элементом «сертификации» интеграций/плагинов редакторов является хорошо определённый процесс, посредством которого пользователи могут сообщать о проблемах, с которыми они сталкиваются при использовании gopls. Производительность и использование памяти не являются блокировками для начального «релиза». Разговор о том, как расширить gopls, начавшийся на конференции для участников в предыдущий день, продолжился с упорством. Несмотря на множество очевидных преимуществ и привлекательности расширения gopls (пользовательские проверки go/analysis, поддержка линтеров, рефакторинг, генерация кода…), пока не существует ясного ответа о том, как реализовать это масштабируемым способом. Те, кто присутствовал, согласились, что это не должно быть препятствием для начального «релиза», но продолжение работы в этом направлении должно продолжаться. В духе gopls и интеграций с редакторами, Хесчи Криник из команды инструментов Go подняла тему поддержки отладки. Delve стал де-факто отладчиком для Go и находится в хорошем состоянии; теперь необходимо установить состояние интеграции отладчика с редакторами, следуя процессу, аналогичному gopls и «одобренным» интеграциям.

Сайт Go Discovery. Вторая сессия по golang-tools началась с отличного введения в Сайт Go Discovery, представленного Джули Цюй из команды инструментов Go, а также с быстрой демонстрацией. Джули рассказала о планах по проекту Discovery Site: открытие исходного кода проекта, какие сигналы используются в ранжировании поиска, как godoc.org в конечном итоге будет заменён, как должны работать субмодули, как пользователи смогут обнаруживать новые мажорные версии.

Build Tags. Далее разговор перешёл к поддержке build tags внутри gopls. Это область, которая, очевидно, требует лучшего понимания (использование случаев собирается в issue 33389). В свете этого обсуждения сессия завершилась с предложением Александра Золотова из команды JetBrains GoLand, что команды gopls и GoLand должны обмениваться опытом в этой и других областях, поскольку у GoLand уже есть большой опыт.

Присоединяйтесь к нам! Мы могли бы легко говорить о темах, связанных с инструментами, целые дни! Хорошие новости в том, что вызовы golang-tools продолжатся в ближайшее время. Любому, кто заинтересован в инструментах Go, очень рекомендуется присоединиться: вики содержит дополнительные сведения.

Использование в корпоративной среде (отчет от Даниэля Теофанеса)

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

Сообщество Go и предложения по развитию языка должны понимать потребности этих менее активных разработчиков. Предложения по Go могут оказывать значительное влияние на то, что будет принято и использовано. Например, папка vendor и позже прокси Go modules имеют огромное значение для компаний, которые строго контролируют исходный код и обычно имеют меньше прямых диалогов с сообществом Go. Наличие этих механизмов позволяет этим организациям использовать Go вообще. Следовательно, мы должны не только обращать внимание на текущих пользователей Go, но и на разработчиков и организации, которые рассматривали Go, но выбрали другое решение. Нам нужно понять эти причины.

Аналогично, если бы сообщество Go обратило внимание на "корпоративные" среды, это открыло бы доступ к множеству дополнительных организаций, которые могут использовать Go. Обеспечивая работу активного каталога аутентификации, пользователи, которые были бы вынуждены использовать другую экосистему, смогут оставить Go в рассмотрении. Обеспечивая работу WSDL, определённая группа пользователей может выбрать Go как инструмент. Никто не предлагал бездумно вносить изменения ради удовлетворения потребностей не-Go-разработчиков. Но мы должны быть осведомлены о неиспользованном потенциале и нераспознанных препятствиях в языке Go и его экосистеме.

Хотя были рассмотрены различные возможности активного сбора этой информации извне, это проблема, для решения которой мы в конечном счёте нуждаемся в вашей помощи. Если вы находитесь в организации, которая даже не использует Go, хотя она рассматривалась, сообщите нам, почему Go не был выбран. Если вы находитесь в организации, где Go используется только для подмножества программных задач, но не для других, почему он не используется больше? Есть ли конкретные блокеры для внедрения?

Образование (отчет от Энди Уокера)

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

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

Это очевидно в официальной документации на golang.org/doc. Она сразу же переходит к тому, как установить язык, прежде чем передать пользователя туру, которая ориентирована на программистов, уже знакомых с C-подобным языком. Оттуда их направляют к How to Write Go Code, который даёт очень базовое введение в классическую рабочую среду Go без модулей, переходя сразу к написанию библиотек и тестирования. Наконец, мы имеем Effective Go, и серию справочных материалов, включая спецификацию, дополненную примерами. Это все хорошие ресурсы, если вы уже знакомы с C-подобным языком, но они всё ещё оставляют многое желать, и не найдётся ничего для новичка или даже для человека, пришедшего прямо с языка, такого как Python.

В качестве доступной и интерактивной точки входа, тур — естественная первая цель для того, чтобы сделать язык более дружелюбным к новичкам, и я думаю, что можно добиться большого прогресса, сосредоточившись исключительно на этом. Во-первых, он должен быть первой ссылкой в документации, если не первой ссылкой в панели вверху golang.org, по центру. Мы должны побуждать любопытного пользователя прыгнуть прямо в дело и начать играть с языком. Также стоит рассмотреть возможность включения дополнительных вводных разделов о переходе с других распространённых языков и различий, которые они, скорее всего, встретят в Go, с интерактивными упражнениями. Это значительно поможет новым программистам на Go в сопоставлении уже знакомых им концепций с тем, что они найдут в Go.

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

• Почему существует так много целочисленных типов, если мне рекомендуют использовать int большую часть времени?
• Есть ли когда-либо хорошая причина выбрать получателя значения?
• Почему есть обычный int, но нет обычного float?
• Что такое каналы только для отправки и только для получения, и когда бы я их использовал?
• Как эффективно компоновать примитивы параллелизма, и когда бы я не хотел использовать каналы?
• Для чего нужно uint? Стоит ли использовать его, чтобы ограничить пользователя положительными значениями? Почему нет?

Тур должен быть там, где пользователи смогут вернуться после первого прохождения, чтобы более глубоко изучить некоторые из самых интересных аспектов дизайна языка.

Но мы можем сделать ещё больше. Многие люди начинают изучать программирование как способ создавать приложения или решать конкретные задачи, и скорее всего они захотят использовать знакомую им среду: браузер. Go пока не имеет хорошей истории фронтенда. JavaScript остаётся единственным языком, который действительно обеспечивает как фронтенд, так и бэкенд среду, но WASM быстро становится полноценной платформой, и у нас есть множество возможностей, куда можно пойти с этим. Мы могли бы предоставить что-то вроде vecty в The Go Play Space, или, возможно, Gio, ориентированный на WASM, чтобы люди могли сразу начать программировать в браузере, вдохновлять свою фантазию и иметь путь миграции из нашей площадки в терминал и далее на GitHub.

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

Платформы обучения (отчёт от Ронны Штейнберг)

Мы обсудили, как должна выглядеть платформа обучения Go, и как мы можем объединить глобальные ресурсы для эффективного преподавания языка. Обычно соглашались, что обучение и понимание легче с визуализацией, и REPL очень приятен для пользователя. Мы также рассмотрели некоторые существующие решения для визуализации с использованием Go: шаблоны, Go WASM, GopherJS, а также генерация SVG и GIF.

Также поднималась проблема непонятных ошибок компилятора для новичков, и мы обсуждали идеи по их обработке, возможно, создание базы ошибок и их полезности. Одна из идей — это обёртка для компилятора, которая объясняет пользователю его ошибки, с примерами и решениями.

Новая группа собралась на второй раунд позже, и мы сосредоточились больше на том, какой должна быть UX-структура платформы обучения Go, и если и как мы можем использовать существующие материалы (выступления, блог-посты, подкасты и т. д.) сообщества и организовать их в программу, из которой можно учиться. Должна ли такая платформа ссылаться на внешние ресурсы? Встраивать их? Цитировать? Мы пришли к выводу, что портал-подобное решение (с внешними ссылками на ресурсы) создаёт трудности при навигации и ухудшает опыт обучения, что привело нас к заключению, что такой вклад не может быть пассивным, и авторы материалов, вероятно, должны будут добровольно соглашаться на размещение их материалов на платформе. Затем возникло много энтузиазма вокруг идеи добавления механизма голосования на платформе, что эффективно превращает учеников в участников, и мотивирует участников размещать свои материалы на платформе.

(Если вы заинтересованы в участии в образовательных инициативах по Go, пожалуйста, пришлите электронное письмо на адрес candoh@google.com.)

Спасибо!

Благодарим всех участников за отличные обсуждения в день участников, и особенно благодарим Lynn, Paul, Daniel, Andy и Ronna за то, что нашли время написать эти отчеты.