Go 1.11 зарелизился — WebAssembly и Нативные модули

    В эту пятницу состоялся релиз Go 1.11. Ключевые вещи релиза — экспериментальная поддержка WebAssembly, а также новая концепция Модулей, которые призваны стать стандартом распространения кода.

    Перед тем, как перейти к главным вещам релиза, стоит сказать несколько слов о не столь заметных пользователю изменениях. Как и в предыдущих релизах, в Go 1.11 была проведена работа по улучшению библиотек языка, тулчейна и рантайма (например, теперь нет ограчений на максимальный размер Хипа). Конечно же, выполнялись работы и по повышению производительности языка (больше всего — в math/big — длинной арифметике).

    Теперь о WebAssembly. На самом деле, на Хабре уже есть несколько статей о том, как писать код для Wasm на Go. Так что, эта экспериментальная фича в релизе — вовсе не новость. Однако, думаю, всем понятно, что это очень важно. Ведь, если у компьюнити получится доработать тулчейн, а также Wasm до production-ready состояния, то мы сможем писать фронтовый код на приятном языке со статической строгой типизацией (привет, javascript!). Вот небольшой пример использования технологии —


    К слову, уже начали появляться разные решения для улучшения жизни программистов для разработки под фронтенд. Например, https://github.com/dave/wasmgo — компиляция Go в WASM, и deploy в CDN в одну команду.

    Теперь перейдём к самому главному, на мой взгляд, в этом релизе — системе Модулей. Про эти модули разговоры уже начались довольно давно. Они были известны миру, как Vgo. Модули даже уже обсуждались в рунете — https://habr.com/sandbox/115542/, а также в рамках подкаста Devzen известным Гофером — Алексеемhttps://devzen.ru/episode-0180/. Хорошее введение в модули — https://roberto.selbach.ca/intro-to-go-modules/.

    Самое главное в этих модулях:

    • Работают по Semver. Причём, команда go mod позволяет, как обновится только на максимальную Патч-версию (третье число версии), так и на любую максимальную Минорную версию (второе или третье число версии). На мажорную версию, которая ломает совместимость, вы автоматически никак не обновитесь — и это очень замечательно.
    • Начат процесс отказа от концепции GOPATH. Разработчики Go хотят уйти от этой абстракции в 2019 году, поэтому уже сейчас новые модули работают только вне GOPATH. Однако можно установить переменую окружения GO111MODULE=on, чтобы убрать это ограничение.
    • Начат процесс ухода от Вендоринга (Vendoring). Пока что, есть возможность в новых модулях положить зависимости в отдельную папку, и использовать их от туда. Однако в будущем разработчики Go хотят уйти от этого. По их мнению, зависимости всегда должны доставаться из репозитория (например, Гитхаб), либо компания должна проксировать репозиторий, кэшируя исходники на своей стороне (например, с помощью Artifactory).

    Важно понимать, что Новые модули — это тоже всё ещё эксперимент. Современные средства разработки ещё не совсем готовы к этому. Поэтому, возможно вам придётся и дальше жить с Dep. Однако уже есть попытки завести Vgo на публичных CI — https://arslan.io/2018/08/26/using-go-modules-with-vendor-support-on-travis-ci/.

    В GoLand новые модули уже существуют, как абстракция. Однако работает всё относительно сыро (например, если вы скачаете модуль, используя Vgo, но не делая go get, то код у вас не начнёт анализироваться):

    image

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

    Комментарии 40

      +4
      > Начат процесс ухода от Вендоринга (Vendoring).

      В vgo наоборот добавили поддержку vendor не смотря на то, что изначально была идея использовать кэш/прокси. По настоятельным и вполне резонным замечаниям общества эту поддержку ввели. Я не видел намеков на то, что это временно и «в будущем разработчики Go хотят уйти от этого».
        –7
        >Тут ничего не сломалось (как и обычно) — и это очень здорово.

        Сломать не сломали, зато удалили кучу «старых» ОС в числе которых Windows XP.
          +3

          Расширенная поддержка этой старой (без кавычек) ОС производителем завершена в 2014 году

            –1
            Сам производитель в vc++2017 позволяет собирать exe
            работающие под Windows XP
              +1
              Все таки направленности у языков разные. Язык общего назначения и преимущественно серверный язык нацеленный на многопоточность и стабильность имеют разные взгляды на поддержку. C++ достаточно низкоуровневый чтобы быть востребованным на любой платформе, а поддержка XP для GO просто избыточна, глупа и только тормозит разработку.
            0
            Можете продолжать использовать компилятор go1.10, если вам нужна поддержка Windows XP. Новых фич с каждым релизом добавляется не очень много, 99% кода может спокойно работать и на версии go1.0, на самом деле.
            0

            эти новые модули — примечательная штука, достойная отдельной статьи. Разработчики высказывались в духе "разрешать зависимости с помощью сведения к NP-полной задаче — все равно что забивать гвозди микроскопом". Большой привет rust с его Cargo и особенно замечательной экосистеме npm+yarn.

              0

              Не уловил, чем модули отличаются от крейтов Cargo. Объясните, если не трудно?

                0
                Мне довольно интересно, а что не так с этими системами? Перекосы, которые случаются из-за того, что какие-то люди решили удалить свои пакеты — это проблемы людей, правда.
                  +1

                  Рассел Кокс написал об этом серию статей: https://research.swtch.com/vgo


                  Если коротко, то основная претензия к Cargo и подобным — то что там игнорируются lock-файлы зависимостей, из-за чего их версии получаются сильно отличающимися от того, что задумывали разработчики этих зависимостей. Из-за этого разработчик приложения может столкнуться с багами и потратить кучу времени на указание подходящих версий. Кокс называет эту ситуацию "low-fidelity builds".


                  В go-модулях используется простой полиномиальный алгоритм, пытающийся выбрать вместо самой новой подходящей версии (как в Cargo и т.п.) самую старую. В результате — простой код без lock-файлов и SAT-солверов (т.к. результат работы алгоритма детерминирован), а версии зависимостей получаются именно теми, какими их задумали авторы, если разработчик явно не указал, чего хочет. Это "high-fidelity builds".

                    0

                    Эм… что-то очень странные претензии ...


                    1. Почему lock файлы игнорируются? Программистами? Это не вина инструмента.
                    2. Вместо указания четкой версии в том же cargo, вполне можно указать промежуток, или даже "эта или любая минорная выше" версия, например.
                    3. В статье написано, что вместо этого есть команда go mod, которая делает тоже самое, что и Cargo пытаясь найти самую новую версию, которая подходит по требования. Чем это отличается от того, что бы просто по умолчанию выполнять установку зависимостей сразу из lock файла и только в каких-то случаях обновлять их? Ну, кроме того, что оно каждый раз запускается и не кеширует результаты, которые не меняются?
                0
                И во сколько раз wasm будет быстрее чем js?
                  0
                  Go уже компилируется в js, что бы сравнивать производительность wasm кода с js?
                    0
                    Да. Правда не официально но в продакшене использовали уже
                    +1
                    Пока что, насколько я понял, он получается намного медленней и объемней :). По крайней мере go -> wasm точно не из соображений производительности сейчас стоит использовать.
                      0
                      Смотря для каких задач.
                      Вот тут, например, довольно забавный бенчмарк на тему процессинга видео, можете поиграться: d2jta7o2zej4pf.cloudfront.net
                      0
                      Так то, да. Язык не предназначен для исполнения в JS среде. Но раз уж речь зашло про wasm, то просто стало интересно чем wasm лучше js. Компилятор go2js гуглится (правда не официальный AFAIU)
                        0
                        JS это язык программирования, а wasm это набор инструкций, для абстрактного процессора. Вещи как бы не сравнимые.
                          +1
                          В теории, wasm позволяет компилировать код «как есть», а транслятор go -> js имеет массу ограничений, например горутины в gopherjs работают немного по-другому. Ну и семантика у go и js тоже разная (например, map'ы в go не сохраняют порядок ключей, а объекты в JS, если ключи не числовые, сохраняют), что тоже плохо сказывается либо на производительности, либо на корректности полученного кода.
                          0
                          *del*
                            0
                            Wasm же еще не поддерживает языки со сборщиками мусора. Как проблему в Go решили?
                              0
                              Очевидно рантаймом самого go.
                              0
                              както wasm и go в моей голове не сочетаются.
                              струдом придумывается сфера применения… клиенты игр?
                                0
                                wasm сейчас многие языки вкручивают. Очевидно, для расширения области применения языка. А что писать — вопрос на совести разработчика. Почему бы и все подряд на нем не писать?
                                  0
                                  go довольно таки специфичный язык.
                                  я пробовал на нем писать что то с бизнеслогикой — неудобно.
                                  ну и структуры данных очень странноватые.
                                  а вот всякие сервисные штукенции — самое оно
                                0
                                А что не так с GOPATH и почему нужно от него избавляться? Про это можно где-то почитать?
                                  0
                                  Возможно, можно начать читать от сюда — github.com/golang/go/issues/17271
                                    +1
                                    А что с ним так :)? Какая-то левая директория, которая нужна для разработки и компиляции, помимо папки с проектом. Многих это сбивает с толку и обосновать её необходимость сложно. Это в гугле на все проекты существует одна версия каждой библиотеки, но во всём остальном мире это вряд ли достижимо. GOPATH заставляет для каждой библиотеки или проекта выбрать _одну_ версию, с которой вы хотите работать, и это бывает очень неудобно. Приходится заводить несколько GOPATH, и становится ещё хуже, по моему мнению.
                                      0
                                      GOPATH заставляет для каждой библиотеки или проекта выбрать одну версию, с которой вы хотите работать

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

                                    0
                                    В GoLand новые модули уже существуют, как абстракция. Однако работает всё относительно сыро (например, если вы скачаете модуль, используя Vgo, но не делая go get, то код у вас не начнёт анализироваться)

                                    что это вообще значит? Как скачать модуль vgo, не делая go get?


                                    Вы зря вообще в статье используете термин vgo, т.к. это не vgo, а go modules (go mod). Vgo — это отдельно стоящий эксперимент по написанию системы модулей, который после слияния с go стал go modules. Это введет в заблуждение большинство читателей.
                                    Следует везде исправить на go modules/go mod, но написать пометку, что раньше это развивалось в проекте vgo.

                                      0
                                      Как скачать модуль vgo, не делая go get?

                                      Если вы cоздадите файл, в котором будет описана зависимость, например, так:
                                      module mod
                                      
                                      require github.com/Hixon10/testmod v1.0.1
                                      


                                      А потом сделаете go build, то нужный модуль автоматически скачается:
                                      go: finding github.com/Hixon10/testmod v1.0.0
                                      go: downloading github.com/Hixon10/testmod v1.0.0
                                      
                                        0

                                        и на каком этапе у меня в goland не будут ресолвиться импорты?

                                          0
                                          У вас модуль будет скачен по другому пути, в отличие от go get. То есть, на моём примере, раньше путь был бы такой:
                                          C:\Go\bin\src\github.com\hixon10\testmod


                                          А теперь такой:
                                          C:\Go\bin\pkg\mod\github.com\!hixon10\testmod@v1.0.0


                                          Поэтому GoLand не может найти модуль, и соответсвенно показать его.
                                            0
                                            У вас модуль будет скачен по другому пути, в отличие от go get.

                                            дело в том, что теперь go get также используется и для скачивания модулей, если он запускается из контекста gomod (т.е. если у вас включена переменная окружения, либо вы находитесь вне gopath). Поэтому go get github.com/Hixon10/testmod@v1.0.1 в директории модуля скачает пакет в pkg\mod


                                            Поэтому GoLand не может найти модуль, и соответсвенно показать его.

                                            для этого в настройках goland нужно включить поддержку vgo для проекта.

                                              0
                                              Интересно, у меня включена поддержка в GoLand для проекта, но проблема сохраняется.
                                              GoLand 2018.2.2
                                              Build #GO-182.4129.57, built on August 23, 2018
                                                +1

                                                смотрите: имеем пустой pkg. Открываем проект в goland. Включаем vgo для проекта (или он уже включен) — в фоне запускается go list, что скачивает в pkg репозитории зависимостей. В дереве файлов появляется пункт Go modules — пока пустой. Делаем go mod download — из скачаных ранее реп в pkg разворачиваются конкретные версии.
                                                И вот тут у меня баг — Go modules все еще пустой (пока не передернешь галочку vgo в настройках или не перезагрузишь всю ide). После этого в Go modules появляются модули и они правильно ресолвятся в коде.

                                      0
                                      А в итоге по модулям — есть какой-то гайдлайн для парней, которые раньше просто делали go get -u '...', а теперь хотят сделать все правильно и по best practices?
                                      0
                                      что за тема оформления консоли на видео (со стрелочками)?

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

                                    Самое читаемое