Перед тем, как перейти к главным вещам релиза, стоит сказать несколько слов о не столь заметных пользователю изменениях. Как и в предыдущих релизах, в 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, то код у вас не начнёт анализироваться):
Подведём итоги. Go 1.11 — отличный релиз. Тут ничего не сломалось (как и обычно) — и это очень здорово. Появились интересные фичи. Мы получили автоматически некоторый прирост производительности. В общем, всё так, как и должно быть в современном языке для индустриальной разработки. А изменения будут в грядущем Go 2, который сейчас активно обсуждается.
Комментарии (39)
Sleuthhound
27.08.2018 09:56>Тут ничего не сломалось (как и обычно) — и это очень здорово.
Сломать не сломали, зато удалили кучу «старых» ОС в числе которых Windows XP.TonyLorencio
27.08.2018 11:17+2Расширенная поддержка этой старой (без кавычек) ОС производителем завершена в 2014 году
pavel_pimenov
27.08.2018 12:46Сам производитель в vc++2017 позволяет собирать exe
работающие под Windows XPIgnisNoir
27.08.2018 15:14Все таки направленности у языков разные. Язык общего назначения и преимущественно серверный язык нацеленный на многопоточность и стабильность имеют разные взгляды на поддержку. C++ достаточно низкоуровневый чтобы быть востребованным на любой платформе, а поддержка XP для GO просто избыточна, глупа и только тормозит разработку.
youROCK
27.08.2018 16:46Можете продолжать использовать компилятор go1.10, если вам нужна поддержка Windows XP. Новых фич с каждым релизом добавляется не очень много, 99% кода может спокойно работать и на версии go1.0, на самом деле.
Laney1
27.08.2018 10:33эти новые модули — примечательная штука, достойная отдельной статьи. Разработчики высказывались в духе "разрешать зависимости с помощью сведения к NP-полной задаче — все равно что забивать гвозди микроскопом". Большой привет rust с его Cargo и особенно замечательной экосистеме npm+yarn.
vitvakatu
27.08.2018 10:56Не уловил, чем модули отличаются от крейтов Cargo. Объясните, если не трудно?
SirEdvin
27.08.2018 11:00Мне довольно интересно, а что не так с этими системами? Перекосы, которые случаются из-за того, что какие-то люди решили удалить свои пакеты — это проблемы людей, правда.
Laney1
27.08.2018 12:37Рассел Кокс написал об этом серию статей: https://research.swtch.com/vgo
Если коротко, то основная претензия к Cargo и подобным — то что там игнорируются lock-файлы зависимостей, из-за чего их версии получаются сильно отличающимися от того, что задумывали разработчики этих зависимостей. Из-за этого разработчик приложения может столкнуться с багами и потратить кучу времени на указание подходящих версий. Кокс называет эту ситуацию "low-fidelity builds".
В go-модулях используется простой полиномиальный алгоритм, пытающийся выбрать вместо самой новой подходящей версии (как в Cargo и т.п.) самую старую. В результате — простой код без lock-файлов и SAT-солверов (т.к. результат работы алгоритма детерминирован), а версии зависимостей получаются именно теми, какими их задумали авторы, если разработчик явно не указал, чего хочет. Это "high-fidelity builds".
SirEdvin
27.08.2018 12:54Эм… что-то очень странные претензии ...
- Почему lock файлы игнорируются? Программистами? Это не вина инструмента.
- Вместо указания четкой версии в том же cargo, вполне можно указать промежуток, или даже "эта или любая минорная выше" версия, например.
- В статье написано, что вместо этого есть команда
go mod, которая делает тоже самое, что иCargoпытаясь найти самую новую версию, которая подходит по требования. Чем это отличается от того, что бы просто по умолчанию выполнять установку зависимостей сразу из lock файла и только в каких-то случаях обновлять их? Ну, кроме того, что оно каждый раз запускается и не кеширует результаты, которые не меняются?
DimPal
27.08.2018 11:10И во сколько раз wasm будет быстрее чем js?
youROCK
27.08.2018 16:48Пока что, насколько я понял, он получается намного медленней и объемней :). По крайней мере go -> wasm точно не из соображений производительности сейчас стоит использовать.
F0iL
27.08.2018 18:07Смотря для каких задач.
Вот тут, например, довольно забавный бенчмарк на тему процессинга видео, можете поиграться: d2jta7o2zej4pf.cloudfront.net
DimPal
27.08.2018 11:33Так то, да. Язык не предназначен для исполнения в JS среде. Но раз уж речь зашло про wasm, то просто стало интересно чем wasm лучше js. Компилятор go2js гуглится (правда не официальный AFAIU)
RPG18
27.08.2018 11:43JS это язык программирования, а wasm это набор инструкций, для абстрактного процессора. Вещи как бы не сравнимые.
youROCK
27.08.2018 16:50В теории, wasm позволяет компилировать код «как есть», а транслятор go -> js имеет массу ограничений, например горутины в gopherjs работают немного по-другому. Ну и семантика у go и js тоже разная (например, map'ы в go не сохраняют порядок ключей, а объекты в JS, если ключи не числовые, сохраняют), что тоже плохо сказывается либо на производительности, либо на корректности полученного кода.
kalininmr
27.08.2018 12:55както wasm и go в моей голове не сочетаются.
струдом придумывается сфера применения… клиенты игр?Guitariz
27.08.2018 13:10wasm сейчас многие языки вкручивают. Очевидно, для расширения области применения языка. А что писать — вопрос на совести разработчика. Почему бы и все подряд на нем не писать?
kalininmr
27.08.2018 13:50go довольно таки специфичный язык.
я пробовал на нем писать что то с бизнеслогикой — неудобно.
ну и структуры данных очень странноватые.
а вот всякие сервисные штукенции — самое оно
pawlo16
27.08.2018 14:07А что не так с GOPATH и почему нужно от него избавляться? Про это можно где-то почитать?
Hixon10 Автор
27.08.2018 16:24Возможно, можно начать читать от сюда — github.com/golang/go/issues/17271
youROCK
27.08.2018 16:54А что с ним так :)? Какая-то левая директория, которая нужна для разработки и компиляции, помимо папки с проектом. Многих это сбивает с толку и обосновать её необходимость сложно. Это в гугле на все проекты существует одна версия каждой библиотеки, но во всём остальном мире это вряд ли достижимо. GOPATH заставляет для каждой библиотеки или проекта выбрать _одну_ версию, с которой вы хотите работать, и это бывает очень неудобно. Приходится заводить несколько GOPATH, и становится ещё хуже, по моему мнению.
zelenin
27.08.2018 17:45GOPATH заставляет для каждой библиотеки или проекта выбрать одну версию, с которой вы хотите работать
есть вендоринг, с которым можно на каждый проект разные версии иметь.
Но в целом конечно смысл существования GOPATH трудно обосновать.
zelenin
27.08.2018 15:19В GoLand новые модули уже существуют, как абстракция. Однако работает всё относительно сыро (например, если вы скачаете модуль, используя Vgo, но не делая go get, то код у вас не начнёт анализироваться)
что это вообще значит? Как скачать модуль vgo, не делая go get?
Вы зря вообще в статье используете термин vgo, т.к. это не vgo, а go modules (go mod). Vgo — это отдельно стоящий эксперимент по написанию системы модулей, который после слияния с go стал go modules. Это введет в заблуждение большинство читателей.
Следует везде исправить на go modules/go mod, но написать пометку, что раньше это развивалось в проекте vgo.Hixon10 Автор
27.08.2018 16:01Как скачать модуль 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.0zelenin
27.08.2018 16:04и на каком этапе у меня в goland не будут ресолвиться импорты?
Hixon10 Автор
27.08.2018 16:22У вас модуль будет скачен по другому пути, в отличие от go get. То есть, на моём примере, раньше путь был бы такой:
C:\Go\bin\src\github.com\hixon10\testmod
А теперь такой:
C:\Go\bin\pkg\mod\github.com\!hixon10\testmod@v1.0.0
Поэтому GoLand не может найти модуль, и соответсвенно показать его.zelenin
27.08.2018 16:27У вас модуль будет скачен по другому пути, в отличие от go get.
дело в том, что теперь go get также используется и для скачивания модулей, если он запускается из контекста gomod (т.е. если у вас включена переменная окружения, либо вы находитесь вне gopath). Поэтому go get github.com/Hixon10/testmod@v1.0.1 в директории модуля скачает пакет в pkg\mod
Поэтому GoLand не может найти модуль, и соответсвенно показать его.
для этого в настройках goland нужно включить поддержку vgo для проекта.
Hixon10 Автор
27.08.2018 16:29Интересно, у меня включена поддержка в GoLand для проекта, но проблема сохраняется.
GoLand 2018.2.2
Build #GO-182.4129.57, built on August 23, 2018
zelenin
27.08.2018 16:42+1смотрите: имеем пустой pkg. Открываем проект в goland. Включаем vgo для проекта (или он уже включен) — в фоне запускается go list, что скачивает в pkg репозитории зависимостей. В дереве файлов появляется пункт Go modules — пока пустой. Делаем go mod download — из скачаных ранее реп в pkg разворачиваются конкретные версии.
И вот тут у меня баг — Go modules все еще пустой (пока не передернешь галочку vgo в настройках или не перезагрузишь всю ide). После этого в Go modules появляются модули и они правильно ресолвятся в коде.
QtRoS
27.08.2018 17:14А в итоге по модулям — есть какой-то гайдлайн для парней, которые раньше просто делали go get -u '...', а теперь хотят сделать все правильно и по best practices?
umputun
> Начат процесс ухода от Вендоринга (Vendoring).
В vgo наоборот добавили поддержку vendor не смотря на то, что изначально была идея использовать кэш/прокси. По настоятельным и вполне резонным замечаниям общества эту поддержку ввели. Я не видел намеков на то, что это временно и «в будущем разработчики Go хотят уйти от этого».