Erlang Hot Code Swapping и интерпретируемые языки

Question

Широко рекламируемая информация о Erlang - это возможность модуляции модулей с возможностью «горячей» замены при запуске приложения и показана как уникальная функция убийцы, недоступная на других языках.

Вот цитата из Joe Armstrong's book:

Большинство серверов выполняют фиксированную программу, и , если вы хотите изменить поведение сервера, вы должны остановить сервер , а затем перезапустить его с модифицированный код.

Хотя в контексте веб-разработки большинство языков поддерживают так называемую «горячую» замену кода, даже не называя его. Это просто обновление кода и публикация его в Интернете через git или непрерывное интеграционное решение.

Я знаю, что у Erlang много приложений в доменах, кроме Интернета, поэтому я уверен, что это имеет смысл в этих случаях.

Но имеет ли эта функция преимущества по сравнению с динамическими языками, используемыми для Интернета, такими как Python, Ruby, JavaScript? Каковы случаи веб-разработки, где он превосходит популярные веб-ориентированные языки?

Answer 1

Эта функция не предназначена для веб-разработки, так как сама Erlang не была создана специально для веб-разработки.

Одна из возможных областей, где эта функция превосходит модель, используемую в общих динамических языках, используемых для Интернета, - это точный контроль над обновлением кода.

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

Answer 2

Горячий код swaping в Эрл предлагает больше, чем возможность обновить код (я не буду делать ни в какое сравнение с Python, Ruby или JavaScript, у меня есть очень ограниченные знания о них):

• Вы можете решить, для каждого узла, когда вы загрузите новую версию кода
• Затем в VM будут присутствовать 2 версии кода, все запущенные процессы будут использовать старую версию каждого модуля до следующей полной квалификации вызывается этот модуль (Mod: Func/arity)
• Если вы используете поведение OTP, сервер (или fsm или gen_event) будет вызываться сначала с помощью code_change call_back, получая в параметрах старую версию модуля , Таким образом, можно проверить, нет или нет, можно управлять обновлением и выполнять любую необходимую операцию в состоянии Data, ETS, синхронизацию процесса ... прежде чем действительно перейти в новый код.
• Если вы не используете поведение OTP, все равно можно получить сообщения формы {system, From, Req}, а затем позвонить sys:handle_system_msg/6, который, в свою очередь, вызовет code_change call_back.