Это если рассматривать в контексте одной ноды.
Как праивльно заметили в дистрибьютед системах, а-ля телеком, написанных на Erlang преобладает философия let it crash. Когда обработчики представляют собой тупые ресиверы сообщений, которые обрабатывают только happy-path. Вся обработка ошибок - лесом, проще переподнять актор, чем на месте решать как обработать ошибку. Это спасет от безобразия вроде недетрменированных ошибок(отвалилась сеть, база..) но не поможет в случае нуллпоинтера) Эрланговцы декларируют надежность как 99.9999.. хз

Верно. Устойчивость к сбоям + нету shared state, что упрощает программирование многопоточности(как минимум mutual exclusion and visibility concerns)

Стримы в шарп это Linq.
Никакого переворота и революции не сделали. Как пришли так и ушли.
Есть огромный сдерживающий фактор у облаков и собирания программ из кусочков.
Сначала вы грезили что будет тонкий экран клиент у всех. А Ось в облаке.
Потом грезили про ворд в облаке.
Потом грезили про микросервисы.
Потом про докеры.
Это ведь все админов касается. Развертывания. Управления ПО. А не РАЗРАБОТКОЙ ПО.
Почему EJB помер?
>И что там обсуждать?
Сначала выясни, это хрень академическая или революционная вещь?
Если второе то нужна ветка в форуме. Отдельная.

Это никак не мешает ООП. Я говорю о том, что ООП в этом случае тебе ничем не помогает
ООП вытсрелил во время доминирующей модели вычислений - когда все приложение крутилось на одном сервере и не то чтобы сильно многопоточном. Имело смысл скрыть shared state под оболочкой переиспользования кода, так и появились обхекты - с ними программы реально было менеджить проще. Но время идет, и сейчас все системы идут в стороны распределнности.облачности\многопоточности, где ООП как гиря на ногах. Сейчас нету никакого практического смысла объединять данные и код по их обработке в одном месте. ФП сложнее чем ООП, оно вносит дополнительные ментальные и инфраструктруные усилия, которые начинают перевешивать именно в распределенных и многопоточных системах.

Начнем с простого
1) Инкапсуляция. Тут надо рассмотреть два аспекта. Shared state - в ФП все иммутабл - значит и инкапсуляция в общем то и не нужна. Второй аспект видимость - чтобы клиент не видел больше чем надо - так тут работают ровно те же техники что в ООП что в ФП.
2) Полиморфизм. Параметрический полиморфизм есть и там и там. Ad-hoc тоже, хотя в ФП он развит больше. Subtype-полиморфизм есть только в ООП - ну и зачем он нужен, что прям без него прожить нельзя? Дальше в 3-м пункте
3) Наследование - Говорить можно долго, но оно создает больше проблем чем решает. Если наследоваться без стейта - то какой смысл? Можно просто выделить функцию и сделать ее парамтерической. Если наследовать со стейтом - то тогда ломаем все принципы SOLID со всеми вытекающими. Код реюз возможен без какого-то либо наследования.
Ну и зачем ООП? Риторический вопрос конечно