Go modules considered harmful

https://www.devever.net/~hl/gomod
Автор то конечно вправе считать как угодно, но я кардинально против его
мнения, как и он кардинально против мнения авторов Go:

* авторы хотят чтобы зависимости в Go прибивались прям жёстко к чётко
  заданной версии. И я полностью поддерживаю это! Я хочу
  детерминированности в поведении. Автор считает что нужно использовать
  семантическое версионирование, но использовать самую последнюю версию
  в пределах совместимости. Потеря детерминированности сборки -- ничто
  не может оправдать. А люди всегда остаются людьми и всё равно рано или
  поздно будут косяки с семантическими версиями
* автор считает что для повторяемой сборки, для детерминированности
  можно и нужно использовать GOPATH просто навсего. Отчасти согласен.
  Точнее я полностью согласен. Но... если нужную версию можно не
  обязательно полностью закоммитить, а указать через хэш в go.mod, то в
  чём проблема? Более того, в чём проблема закоммитить всё что хочешь в
  vendor директорию?
* у меня стойкое ощущение что автор не до конца понял как работать с
  модулями. GOPATH deprecation нисколько не убирает возможность гвоздями
  прибитые версии софта использовать и коммитить рядом, класть через
  submodule или как угодно ещё
* автор много пишет про то, что он не хочет видеть несколько версий
  одной и той же библиотеки у себя в программе. Согласен -- неприятно. А
  что делать? Я так и не увидел его предложение что делать со случаем
  когда A зависит от B версии vX, а C зависит от B версии vY. Хотя он
  упоминает семантическое версионирование gopkg.in-style... которое
  идентично must-have-to-use семантическому версионированию в модулях.
  Автор, так ты прочь или не прочь использовать несколько версий
  библиотеки? С модулями все возможности остаются. А вот в Python
  действительно подобную ситуацию вообще никак не разрешить из коробки
* автор считает что из-за жёстко привязанных версий у package maintainer
  нет средств использовать немного другие версии. Я считаю это хорошо --
  детерминированность это хорошо, и всегда лучше её отсутствия. А если
  кому очень надо что-то поменять -- go ahead и делай правки, накладывай
  патчи, как это было всю жизнь всегда
* всё что автор написал касательно централизации распространения модулей
  -- бред. По мне, так это буквально точно такое же популярное мнение
  что git это значит использовать Github. В Go можно запускать свои
  proxy, вообще их не использовать, делать replace внутри go.mod --
  средств огромная масса чтобы делать всё что угодно и как угодно. Лично
  я вообще не привлекаю нигде инфраструктуру Google при работе с Go
* такое ощущение, что куча хотелок автора решается replace в go.mod,
  что не возбраняется и не запрещается

Я отчасти во многом похож с автором: я активно использовал GOPATH для
предоставления зависимостей в проект. Признаюсь, впервые когда я увидел
GOPATH deprecation, то подумал что как теперь быть то? Как теперь
предоставлять в едином tarball-е всё что нужно? Копнув глубже, понимаешь
что vendoring полностью идеально решает эту задачу, никаких проблем. И
даже поудобнее. И даже никакого дополнительного инструментария не надо
использовать.