Хабрахабр

[Перевод] Следующие шаги на пути к Go 2

13, релиз которого, надеюсь, состоится в начале августа этого года. Мы вовсю работаем над Go 1. Это первый релиз, который будет включать в себя изменения конкретно в языке (а не просто незначительные правки спецификации) после длительного моратория на любые такие изменения.

Мы хотели, чтобы первичный отбор предложений нами играл относительно малую роль и, по большей части, не вызывал споров, чтобы с большой вероятностью они бы прошли весь этот процесс. Чтобы прийти к этим изменениям в языке, мы начали с нескольких жизнеспособных предложений (proposals), отобранных из гораздо большего списка предложений по Go 2, в соответствии с новым процессом оценки предложений, описанным в посте "Go 2, here we come!". Коротко, текущий начальный этап изменений был больше направлен на то, чтобы снова сдвинуться с мертвой точки и получить опыт, а не на решение больших проблем. Предложенные изменения должны были быть обратно совместимыми, чтобы сломать как можно меньше, поскольку модули (которые в будущем позволят выбрать версию языка для конкретного модуля) пока еще не являются режимом сборки по умолчанию.

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

13, пришло время задуматься о будущем Go 1. С учетом этих начальных изменений в Go 1. 14 и определить, что мы хотим изменить далее.

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

Остаются улучшение обработки ошибок и дженерики. С улучшением системы модулей Go решается проблема управления пакетами и версиями. С тех пор мы постепенно улучшали их. Мы работали над обеими проблемами и представили черновики дизайн-документов на прошлогоднем GopherCon в Денвере. ниже). По обработке ошибок мы опубликовали значительно переработанное и упрощенное предложение (см. Что касается дженериков, то мы работаем над этим, на эту тему на GopherCon в Сан-Диего в этом году состоится выступление Иэна Лэнса Тейлора "Generics in Go", однако мы пока не дошли до этапа, когда могли бы предоставить конкретное предложение.

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

Встроенная функция проверки на ошибку — "try" (дизайн-документ). #32437.

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

Разрешить встраивание перекрывающихся интерфейсов (дизайн-документ). #6977.

Это старое обратно совместимое предложение для того, чтобы сделать встраивание (embedding) интерфейсов более толерантным.

Предупреждать о преобразовании вида string(int) в go vet. #32479.

Поскольку удаление этого преобразования не является обратно-совместимым изменением, мы предлагаем вместо этого выдавать ошибку при выполнении go vet. Преобразование вида string(int) давно было добавлено в Go для удобства, однако оно очень путает новичков (string(10) — это "\n", а не "10") и более не оправдано, поскольку сейчас преобразование доступно в пакете unicode/utf8.

Принять принципы проектирования по криптографии (дизайн-документ). #32466.

Смотрите также соответствующее предложение по удалению поддержки SSLv3 из crypto/tls. Это запрос обратной связи по набору принципов проектирования криптографических библиотек, которые мы хотели бы принять.

Мы особенно заинтересованы в фактических данных, показывающих, почему предложение может работать плохо на практике, или в проблемных аспектах, которые мы могли упустить при разработке. Мы активно собираем обратную связь по всем этим предложениям. С другой стороны, комментарии, содержащие только личные мнения, менее действенны: мы можем принять их во внимание, но не можем конструктивно работать с ними. Убедительные примеры в поддержку предложений также очень полезны. Ваша тема, возможно, уже была поднята и обсуждена в предыдущих комментариях, особенно в ходе долгих дискуссий. Перед ответом, пожалуйста, найдите время, чтобы прочитать подробные дизайн-документы и предыдущие отзывы или их краткое содержание.

14 (начало августа 2019 г.), чтобы это уже можно было оценить на практике. Если эти предложения не встретят явных проблем, то мы планируем все реализовать в начале цикла разработки Go 1. В соответствии с процессом оценки предложений, окончательное решение будет принято в конце цикла разработки (начало ноября 2019 г.).

Спасибо за помощь в улучшении языка Go!

Robert Griesemer, для команды Go

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть