Там, где нужна отказоустойчивость, где огромное число клиентов и «плохое» поведение одного из них не должно обрушить всю систему, плюс допускаем, что наш код не идеален — и со всем этим надо как-то жить в продакшене.
Как-то друг показал программу типа «Ping-pong» (клиент отсылает серверу строку «Ping», сервер должен прислать «Pong»), не помню из какой книги. Мне понравилось то, что занимала она меньше 40 строк. Я пообещал в ответ написать аналогию на C# до 50 строк… В общем, если не считать необрабатываемых исключений — уложился.
Но идейность и мощь Erlang-а очевидна. Вспомнить хотя бы Yams vs Apache.
ну, например в win32 есть те-же самые fiber-ы. За одним исключением — логику переключения с фибера на фибер надо самому писать. Но ведь все её уже написали, надо только в сорцах покопаться, так? :)
А изоляция файберов друг от друга? А посылка сообщений? В каком-то смысле процессы Erlang-а довольно близки к объектам в ООП (в Смоллтолковском понимании). Это тоже стоит учитывать. Ну и вот пример с Fiber-ами из msdn: msdn.microsoft.com/en-us/library/ms686919(v=vs.85).aspx. Стоит ли пробовать выразить то же самое на Erlang, чтобы проверить, что в случае win32 эта затея не имеет особого смысла?
Да есть, toolbar:start() — тулбар со всеми инструментами. Отладчик debugger:start(). Этим отладчиком ни разу не пользовался, просто не было надобности. В своих проектах в основном использую утилиты tv — если надо залезть в таблицы mnesia и appmon, чтобы посмотреть дерево процессов приложения.
По поводу прямой работы с процессами согласен, OTP супер. Просто чтобы понимать как там внутри все работает стоит все же поближе познакомиться с «сырыми» процессами.
Я правильно понимаю что только в Erlang реализована вытесняющая многозадачность для процессов виртуальной машины? Во всех остальных реализациях модели акторов (например в akka) вы не можете просто так взять и выполнить блокирующую операцию.
Erlang и его процессы