Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Cyberax, Вы писали:

C>>Потому, что в Эрланге она намного мощнее. Тут я это уже объяснял.

IT>Мощнее понятие недетерминированное.

Вполне детерминированное, если подобрать адекватную для рассматриваемого вопроса классификацию. В вопросе замены кода на лету, основными граничными элементами являются:

1. Возможность гладкого, незаметного для посторонних перехода. То есть подход "выгоняем всех, выгружаем старые DLLки, загружаем новые, запускаем клиентов" будет хуже и менее мощным, чем возможность сделать то же самое, сохраняя старый код, пока он используется. Возможность перейти в уже существующей работе с одним клиентом на новый код, не вызывая аварийного завершения соединения и сброса связанного с ним контекста, является показателем большей "мощности", чем необходимость доработать старым кодом со всеми, кто его уже начал использовать.

(Я использовал тут для ясности понятия "клиент" и "соединение". Но этот подход можно использовать и там, где таких понятий нет или они называются иначе — как, например, процесс и открытый файл на FS, если нужно обновить драйвер FS. Основной момент в тех условиях, которые в принципе требуют формулировки понятия "на лету". Если работа с чем-то идёт по методу "открыл-чихнул-закрыл", тривиально организовать момент, когда ничего не "открыто" — и вопрос о замене на лету не стоит.)

2. Возможности самого процесса перехода — как он реализован, насколько гладко и просто выглядит сам процесс перехода со всеми необходимыми действиями (в первую очередь конверсию данных существующих соединений в форму, которая необходима для новой версии).

Сравнивая известные мне среды, Erlang'овая реализация действительно является одной из максимально мощных, потому что:

1. Позволяет провести замену кода максимально быстро и прозрачно для приложения, незаметно для всех существующих соединений. На момент отработки запроса о запуске нового кода, со старым кодом будут работать только те процессы, которые уже с ним начали отрабатывать одно входное сообщение. При рекомендованной организации кода (по стандартам OTP) это доли секунды, в худшем случае единицы секунд (если отработка сообщения требует синхронного вызова чего-то длительного внешнего).
2. Содержит средства организации апгрейда (называемые relup), автоматизирующие выполнение этого процесса для широкого набора случаев.

Python'овая реализация:

1. Позволяет провести замену кода максимально быстро и прозрачно для приложения, незаметно для всех существующих соединений — но для этого требуется организация выполнения в уже известном стиле Erlang'а: чтобы один и тот же код для одного соединения выполнялся или отработкой целевых действий, или апгрейдом, но не одновременно. Иначе, возможности другие, но тоже симпатичные — можно существующие соединения отрабатывать старым кодом сколь угодно долго (и вручную разбираться с последствиями такой организации;))
2. Автоматизации апгрейда нет, надо организовывать свой закат солнца вручную именно для данного приложения.

А теперь если сравнить, например, с Java (сразу дисклеймер — все мои знания про эти её возможности только по документации) — организация кода в виде именованных классов с глобально уникальными именами (причём фиксированными в момент компиляции кода) резко усложняет возможность замены кода на лету, ибо существование двух одноимённых классов невозможно — а, значит, замена потребует
1) сохранения всех данных, хранимых в объектах этих классов, в некотором внешнем (для них) хранилище (в памяти, чтобы сохранить всякие открытые файлы)
2) собственно фазы перезагрузки кода
3) восстановления состояния из хранилища

что может длиться уже секунды, а то и минуты, с остановкой всей полезной работы.

Насколько я знаю, в .NET точно так же. Если ошибаюсь — исправьте, это будет мне полезно в плане оценки, куда двигать систему дальше.

На основании этих примеров можно вывести числовую оценку мощности механизма замены кода. Начнём с того, что отсутствие такой возможности оценим в 0 баллов:) Далее, возможность сосуществования старого и нового кода штатными средствами языка/среды ,оценим в 50 баллов, возможность поддержки более двух версий — в 60 баллов для языков с организацией на сообщениях и 70 — на общей памяти. (Это, конечно, грубо, потому что на сообщениях можно писать на всех;)) Стандартную поддержку замены кода соответствующим библиотечным кодом оценим в зависимости от мощности этой поддержки — до 50 баллов (Эрланговая примитивна и недостаточна для случаев конверсии межпроцессной логики, но более простые случаи исполняет "на ура", дадим 30.)

Итого: Erlang — 80 баллов. Python — 70. Java (JVM) — 10. .NET — 10. По остальным — пусть расставляют те, кто их достаточно знает и может оценить.

Достаточно это для детерминации понятия мощности данной возможности? ;)