для многих проектов потом наступает стадия "просто работа", и часто это 1 админ и 0 программеров.обычно там пол программера или даже треть. Получется один программер на несколько проектов занимается вялотекущими правками. Под его хотелки надо доставлять библиотеки или обновлять имеющееся ПО. Помню эпический гемоморой с одной библиотекой php. пришлось собирать из исходников и вкарячивать в проект.
все 10 лет штатные репы доступны, не надо как у дебов править репы, прописывать архивы, вносить правки в конфиги чтобы "апдейты были больше года назад, нибуду роботать" и прочие сюрприз-механики.тут ещё одна вишенка. Обычно репы ставятся с пол пинка, не требуют шаманств с их установкой и не устраивают бесконечные конфликты зависимостей.
даже "свежие" дебы как минимум на год отстают от реальноони считают это фичей и даже хвалятся этим.
всякие pip-npmв мире Дебиан это боль. Либо старое, либо конфликтующее, либо нехватает кучи пакетов по зависимостям. Аналогичный головняк с пакетами php.
Правильно ли я понимаю, что задержка пакетов в таком случае непостоянная величинаСовершенно верно
иногда соединение стабильно, иногда нетЕсть возможность возможность ответить на этот вопрос самостоятельно. Просто поработать инженером (не техподдержкой на телефоне) у провайдера. Пару раз уронить линки, оставить несколько регионов без связи, накрутить колец для пакетов. Всё это и не только довольно просто делается и происходит довольно не редко.
Go изначально задумывался как ЯП, который сможет быстро освоить любой, кто базово знаком с программированием, дабы Google мог нанять тысячу джунов и они быстро прототипировали идеи без заморочек C/C++пруфы будут, что именно из этих рассуждений исходили Роб Пайк и Кен Томпсон после разработки ОС Plan9? Или опять бабки казали, что на заборе что-то видали?
А еще вся супер-пупер параллельность - на самом деле асинхронщина, работающая на небольшом пуле реальных потоков ОСВ go не используются потоки ОС. В этом плане это самодостаточный ЯП.