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

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

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

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

Все таки направленности у языков разные. Язык общего назначения и преимущественно серверный язык нацеленный на многопоточность и стабильность имеют разные взгляды на поддержку. C++ достаточно низкоуровневый чтобы быть востребованным на любой платформе, а поддержка XP для GO просто избыточна, глупа и только тормозит разработку.
Можете продолжать использовать компилятор go1.10, если вам нужна поддержка Windows XP. Новых фич с каждым релизом добавляется не очень много, 99% кода может спокойно работать и на версии go1.0, на самом деле.
UFO landed and left these words here

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

Мне довольно интересно, а что не так с этими системами? Перекосы, которые случаются из-за того, что какие-то люди решили удалить свои пакеты — это проблемы людей, правда.
UFO landed and left these words here

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


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

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

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

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


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

Как скачать модуль 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
У вас модуль будет скачен по другому пути, в отличие от go get. То есть, на моём примере, раньше путь был бы такой:
C:\Go\bin\src\github.com\hixon10\testmod


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


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

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


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

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

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

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

А в итоге по модулям — есть какой-то гайдлайн для парней, которые раньше просто делали go get -u '...', а теперь хотят сделать все правильно и по best practices?
Only those users with full accounts are able to leave comments. Log in, please.