Мне этот язык не нравится, чисто с админской стороны.Есть, например, небольшая программка на Go. Небольшая - зависимостей 10-15. Вопрос, который меня убил - как ее собрать в пакет?
Изучив то что было на тот момент в Go 1.14 по вытягиванию зависимостей, я был в ужасе.
Получается, что чтобы собрать программу текст которой содержит внешние зависимости от других библиотек, мне нужно... скачать их из какого-попало гитхаба/гитлаба и прочего.
В гитхабе оно привязывается к тегу ну или бранчу... не важно. Главное что признаком нужной версии в конечном итоге является хэш коммита. НО! Пакетный менеджер Go видит тег, а не хеш. То есть теоретически если программа prog1 версии 0.1.0 требует библиотеку lib1 версии 1.0.4, то 1.0.4 будет тегом, который разработчики lib1 могут поменять.
Видимо программистов на Go не учили что такое "релиз" и, типа, это нормально зацепиться зависимостью на какой-то бранч в который в конечном итоге могут закоммитить и что-то поломать. И вот эта байда по всему Go.
Fedora, например, решает проблему так:
1. Написать спек для каждой библиотеки, от которой зависит программа так, чтобы результирующий SRPM проверял не только тег, но и хэш коммита
2. Писать спек rpm который будет тянуть код для сборки программы не из git, а из специально оформленных SRPM-пакетов с кодом зависимостей.
В этой схеме получается, что есть тьма-тьмущая пакетов, которые используются только как зависимости, но отдельно не собираются. Каждый из них нужно сопровождать, отслеживая факт "фикса", когда разрабы поменяли либы, поменяли тег или когда приложение затребовало другую версию в связи с обновлением. Кроме того надо тянуть в репозиторий зоопарк из версий одной и той же либы.
Судя по обсуждениям и объяснениям, RedHat решил себе столько работы придумать, потому что не уверен в том, что завтра, послезавтра или через 5 лет программа из репозитория соберется, если у нее есть внешние бесконтрольные зависимости. Debian, как я понял из новостей про kubernetes решил что "и так сойдет", но я не проверял, это не точно.
Просто если дать Go-компилятору волю, он именно в инет на git полезет за своими зависимостями. Какие-то идеи по надежному сопровождению, гарантии, повторяемость сборки летят псу под хвост, если не обмазаться сотнями SRPM-ок на Go... с одной стороны. С другой стороны, работы на пустом месте оно создаёт так много, что лучше программы на Go просто не поставлять ни в составе дистров, ни в собственных корпоративных репозиториях. Только бинарно, построив отдельную специфичную для Go систему сборки и тестирования.
У питона, например, таких проблем нет, потому что питоновское барахло имеет релиз.
Если у вас на предприятии кто-то хочет писать на Go программу, которую нужно сопровождать Вам, постарайтесь донести до менеджмента, что наличие кода на Go увеличивает нагрузку на техподдержку. Микросервисы в кубиках пусть пишут, но не больше. Благо, с ними девопсы мучаются в отдельном CI/CD, а не техподдержка.
