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

N>>2. Erlang имеет ряд тяжёлых специфических болезней. Например, неуправляемый входной поток данных — убийство VM.
N>>На практике против последствий этого строят сложные системы управления.
F>это как "неуправляемый"?

Процесс не может регулировать, что ему отправляется в mailbox. Mailbox один для сообщений всех типов и источников. При его большой длине синхронные взаимодействия начинают стоить пропорционально длине очереди каждое, а в сумме получается квадратичная зависимость. Некоторые действия даже по избавлению от данных (как gen_tcp:send) требуют обратного приёма сообщения, соответственно, там получается то же O(n^2).

F>и о каких системах речь?

Лев Валкин (lionet@), например, строил демпферы на точках передачи между нодами, оповещая их о состоянии приёмных процессов. У него целый фреймворк был для этого.

N>>Или куча процесса — если процесс толстый, можно не суметь её собрать — это к тому, что глобальный GC может быть даже лучше, чем на отдельный внутренний процесс.

F>а тут что помешает?
F>gc же на каждый шедулер, а не на процесс.

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