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

F>>>2. отказоустойчивость в случае ошибок (система не должна зависать и падать в принципе)

_>(и все же философия эрланга — все падает, deal with it)

Этот пункт был специально обозначен neFormal-у дабы показать, что некорректно предъявлять такое требование к конкурентам Erlang-а, если сам Erlang не в состоянии его выполнить. Причем как раз за счет одного из основных принципов -- let it crash, который воплощен в жизнь не только для легковесных потоков, но и для самой Erlang-овой VM.

Так что пункт "система не должна зависать и падать в принципе" не относится к Erlang-у в принципе.

S>>Загляните, пожалуйста, в исходники Erlang/OTP, в функцию erts_alc_fatal_error в частности. И объясните, как это ваше требование выполняется в Erlang-е, где невозможность аллокации памяти приводит к завершению работы всей VM.

_>Так а что еще делать, если память кончилась?

Если аллокация была инициирована из Erlang-ового кода, то можно бросить исключение.
Если из нативной NIF-ки, то почему бы не вернуть из nif_alloc_resource NULL вместо аборта всей VM.

Допустим, приходит (N+1) клиент, дергается реализованная в NIF-е функция, там вызывается nif_alloc_resource и оказывается, что очередные 128 байт для этого клиента выделить не удается. Вместо того, чтобы вернуть NULL из nif_alloc_resource и какой-нибудь тупл {err,code} из NIF-функции, дабы потом в Erlang-овом коде просто убить созданный для (N+1) клиента процесс, грохают всю VM.

_>А на практике, если вы не забыли про erlang:system_monitor а vm упала с out of memory,

На практике Erlang хорошо тормозит и падает даже у тех, кто знает про system_monitor.

_> 99% что утечки в c++ (ниф или драйвере), и не совсем честно считать это проблемой эрланга.

Собственно, об этом и было сказано по ветке выше: как только из-за родных тормозов Erlang-а в приложении оказывается достаточное количество кода, достоинства Erlang-а испаряются и Erlang превращается в такой же клеевой динамически-типизированный язык, как Python/Ruby/Lua и еще куча других.

Но там же было сказано и более важное: нельзя предъявлять к C++/Scala/C#/Haskell/Ada и пр. такую претензию, что в этих языках нет фишек Erlang-а. Конечно их там нет. Более того, очевидно, что их там и не может быть (особенно если язык нативный). Но для решения таких же проблем concurrency computing и distributed computing в этих языках просто-напросто будут использоваться другие подходы и другие инструменты. И результат будет получаться не менее достойный.

Так что, если кого-то устраивает Erlang, то почему просто не использовать его и не делится success stories? Отличный язык, отличная VM, отличные библиотеки для него.
Только не всем подходят. А у тех, для кого Erlang не подходит, есть другие языки и другие инструменты.