Виртуальные машины не то чтобы зло...

[vak]

При прочих равных я всегда предпочитаю родные бинарники. Серьёзная программа должна выполняться в машинных кодах, как предписано разработчиком процессора. Виртуальных машин избегаю по возможности. Они обычно только вносят лишнюю сумятицу.

К примеру, Питон, отличный язык, но построенный вокруг специальной виртуальной машины. Вопрос на засыпку: сколько разных копий Питона установлено на вашем компьютере? Я глянул на своём маке:

• собственно Питона установлено четыре версии: 2.7, 3.8, 3.9, 3.10
• копия Питона 3.7 внутри приложения LibreOffice
• три лишних копии Питона 3.8 в приложениях XCode, Apple CLI Tools и KiCad
• ещё одна копия Питона 3.9 в компиляторе для ESP32
• плюс десять копий Питона 3.10 в утилитах awscli, bpytop, gallery-dl, glances, meson, scons, sip, sphinx-doc, xonsh, youtube-dl

Итого 19 штук одного Питона. Отдельно можно посчитать Java, .NET, Ruby, Guile, Lua и другие. Налицо нездоровая тенденция виртуальных машин плодиться и замусоривать пространство. Версии плодятся, и чтобы избежать проблем несовместимости каждый софтверный продукт стремится тащить с собой отдельную копию каждой виртуальной машины. 

Comments

[ircicq]

Это проблема DLL hell - более общая, и свойственна не только виртуальным машинам.

Любой крупный продукт тащит привязку к конкретным версиям shared libraries,
а уж containerized-приложения по-определению.

[vak]

Верно. Это в целом проблема зависимостей от сторонних компонентов. Но в случае VM-based языков она усугубляется. Для родных бинарников действует обещание производителя операционки изменять интерфейсы только совместимым образом, чтобы старые бинарники продолжали работать. В случае виртуальных машин всё гораздо хуже.

[x86128]

Проблема есть, какого-то универсального решения - нет.
А решать как-то надо, вот инженеры и придумали (в век резиновой памяти) запекать все в навозные шарики контейнеры и поставлять пользователям чтобы зависимости были только от ядра ОС.