0.6 - это довольно много.
При том, что это только цена запуска, а не цена перестройки меша/балансировки (сколько времени оно там занимает), цена перезапуска внешних сценариев по http timeout (на сколько он выставлен у клиента твоего сервиса?) и так далее.

Ну да, такая модель. Закрытые бинари не особо любят и инструментов для них - только ffi

Угу. Нормальная модель - но для многих вариантов использования - не подходит (для того же энтерпрайза)
Или для поставки b2b энтерпрайзу.

Так не затягивайте.

Статические сборки — зло. Они нужны для считанных случаев вида «bash в single mode». Для всего остального (кроме embedded) это только проблемы.

Все, что я видел на go - это статические сборки с кучей разных версий библиотек. А на вопрос разработчикам "зачем вы патчили такую-то версию такой-то библиотеки?" мне ответили "у тебя есть исходники, посмотри сам". Вопрос "зачем" они, кажется, не поняли...

Вас никто не обязывает каждый патч тянуть в прод. Конечно, если это не некро-BSD, где сборка ядра на проде — нормально, хехехехе

Сборка ядра во фряхе на проде имела глубокий смысл, когда на сервере было 16-32 мегабайта оперативки. "Собери ядро и сэкономь мегабайт памяти" - было ценной фичей. С тех пор - я не очень представляю себе человека, который этим будет заниматься не от избытка дури.

эм, при патче зависимостей сделали PR без комментариев и ченжлога?
это точно от языка зависит, а не от культуры/процессов? (ну или я не так понял)

А вот отсутствие динамического связывания — проблема. Когда баг в опенссл, а пересобирать проект тебе.

Вообще, чем меньше жёстких связей в проекте — тем лучше. Поэтому и микросервисы, и прочая распределёнка.

А статическая сборка — прошлый век.

Бгг. Программа по определению доверяет окружению. Она же не в ring0 работает, и в принципе не может в контроль памяти))

Там жы виртуальная память с отображением. Подменить можно любой блок. И программа ничего проверить не сможет.

Однажды, лет 20 назад, старший товарищ (не глупый и чуткий) рассказывал в курилке о своей первой работе. На эту историю его навел тот факт, что у нас переехал офис и мы заселились на территории бывшего завода, собственно где и случилась эта история.
Они в начале 80х здесь делали железку. Железка должна была весело помаргивать светодиодами на стенде в зависимости от прогоняемых тестов. Все было замечательно, но через 30 секунд внутри железки что-то увлекательно вспыхивало и распространяя запах изумления она замирала.
Пытливый ум юных ньютонов несколько недель безуспешно пытался решить проблему. На носу были испытания и сдача заказчику. В душе было грустно и холодно...
На удивление все прошло хорошо.
Устройство отработало на стенде 25 секунд (как было заказано) и все довольные разошлись в мыслях о премии.
Товарищ негодуя дошел до своего начальника и поинтересовался - как так? Она ж через 30 секунд обязательно сломается! На что получил ответ: и хорошо, лететь ей не более 20, потом ракета самоликвидируется.

Гу вообще говоря, для ракетной техники есть масса комплектующих со сроком службы в часы. Пять минут полёта плюс подготовка к старту плюс плановые проверки.
На самолёте МиГ-21 аварийная насосная станция имеет срок работы 30 минут.

Но когда мы говорим о сдыхающих контейнерах это уже совсем другая история. Неумение и нежелание сделать сервис нетекущим — не доблесть, а демонстрация отсутствия образования.

Для этой истории, секунды - драматичнее.

читал про французских ракетчиков, у которых в системе не было сборки мусора, да и пофиг, потому что работает программа один раз, главное, чтобы хватило долететь

И, если у разрабов течет память и всем ок, то, скорее всего, где-то рядом живет и buffer overrun и всем ок (пока не взломают). Ну, или elasticsearch на дефолтном порту без пароля.

... это по такому подходу они Ариан долбанули?

и чтобы ракета не дай бог не зафрилизилась

другие ракетчики )) из Dassault

Но преемственность национального подхода чувствуется!