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

_>>>попытками запустить 100000 нитей ОС с неизвестной целью

EP>>Как это с неизвестной?

_>Цель неизвестна, т.к. за этим последовало слишком много "но", и в итоге здравый смысл победил (что не нужно на С++ повторять модель Эрланга, и что "Мной нигде не утверждалось, что шедулеры традиционных ОС так же хорошо справляются с сотнями тысяч потоков, как VM Erlang-а."). Он мог и без боя победить.

Во-первых, про цель запуска 100000. Это была наглядная демонстрация возможностей современных 64-битовых ОС. Т.к., оказалось, что многие еще мыслят категориями 20-летней давности, когда количество нитей, разрешенных к созданию в каких-нибудь OS/2 или Win NT 3.5 было ограниченно жестким лимитом. Нынче 100K нитей можно создать даже на Win8 Home, и на совсем не ТОП-овом железе.

Во-вторых, "Он мог и без боя победить". Начиная с самого первого ответа

Автор: so5team
Дата: 04.06.15

Mamut-у я провожу простую мысль. Хоть и приходится ее формулировать по-разному:

Начинать нужно с того, что подход Erlang-а к решению проблем concurrent computing не единственный возможный. Т.е. если выделять отдельный процесс под выполнение какой-то активности от начала и до конца, то здесь Erlang вне конкуренции за счет того, что у него собственный шедулер и сборщик мусора, успешно поддерживающие работу сотен тысяч легких процессов.

Существует и другой подход, который принято называть SEDA-way, при котором отдельный процесс/нить заводится не под всю активность, а под определенную операцию (stage) в рамках активности. Сами же активности могут оформляться либо в виде легковесных короутин, либо в виде еще более легковесных объектов (конечных автоматов). Задача этих объектов всего лишь передача сообщений между stages.

или

Но суть в другом: не нужно работать с потоками ОС так же, как с легковесными процессами Erlang-а. Соответственно, повторю в очередной раз: в большинстве распространенных языков нет того, что есть в Erlang. По определению. Тем не менее, задачи из области parallel-, concurrent- и distributed computing на этих языках решаются ничуть не хуже, чем на Erlang-е.

Тем не менее, эвангелисты Erlang-а упорно продолжают твердить, что если в каком-то другом языке/платформе нет всех фишек Erlang-а, то Erlang круг по определению. На что остается только в очередной раз повторить: да, в поддержке фич Erlang-а у Erlang-а нет серьезных конкурентов. Это так, и с этим глупо спорить. Не менее глупо спорить и с тем, что для многих задач и для многих разработчиков эти хваленые фичи Erlang-а не нужны чуть меньше, чем совсем. Благодаря чему и без Erlang-а строятся и эксплуатируются системы разных масштабов, важности и сложности. До масштабов некоторых из них Erlang-у, возможно, никогда и не добраться.

Что вовсе не означает, что Erlang плох и что нужно его всячески игнорировать. Как и любой успешный инструмент, он имеет свое место, свои достоинства и недостатки. Хотелось бы, чтобы это понимали и Erlang-евангелисты.