del, не верно прочел исходный пост

1. А был ли мальчик? То есть "профит"
2. Назвать akka фреймворком, на мой взгляд достаточно сложно. Попытка портировать некоторые принципы из Erlang'а (или откудо-то еще) с урезанием того, что с JVM не скрестилось.

Как раз основные проблемы возникали на уровне связи фраймворки/API (например JavaNIO) и AKKA-код. Если бы на акторах была __вся__ инфраструктура (IO, web, GUI и т.д.), то можно было бы говорить о полноценной среде/фреймворке. Но ведь этого нет. И, подозреваю, не будет.

AFAIK В том же самом Erlang, все инфраструктура построена на акторах. С AKKA же получается мешанина легаси_Java + акторы.

Если же вообще расматривать полную AKKA Инфраструктуру - то все безумно сложно и не дешево. Например профилировшики, которые могут в проекте/кластере показывать/отслеживать загруженность очередей конкретных акторов. Фиг знает, как настроить динамическую балансировку, что бы при загруженности конкретных акторов как-то динамически запускать дополнительные копии. Программные средства такие есть, но когда интересовался: a) они были достаточно сложны b) стоили денег и не маленьких. Фиг знает, как нужно дорабатывать архитектуру приложения, что бы оно было совместимо с этими средствами.

В общем. На словах все легко и просто. На деле - сложность решения и _сопровождения_ решения зашкаливает.

Что мешает делать проекты event driven и без AKKA - мне не понятно. Достоинства которые рекламируют, типа возможности запускать на кластере и легко раскидывать акторы по разным узлам - на словах хорошо, но представляя цену такого подхода (разница в латенси между сообщениями в памяти и в сети), у меня волосы становятся дыбом и то, что все будет работать "само и быстро" - я не верю.

IMHO & AFAIK

Ну и я не понимаю базовой веши.

Вот есть у меня прикладная задача. Допустим биллинг или бухгалтерия или склад. Крупный. Есть бизнес объект СЧЕТ

В парадигме СУБД - счет будет запись в таблице bills
В парадигме ООП - счет будет инстанс класса Bill. От одного этого, у СУБДшников волосы дыбом встанут. Но Гради Бутч считал (книга Объектно ориентированное программирование и анализ. 1990-ые годы), что это правильно. Память на серверах иногда заканчивается ))), но зато все ООПшно )))

Что это будет в парадигме акторного проектирования: это должно быть событие или актор?

По хорошему, вроде актор. Но представить систему с 100500 тысячями акторов Счет и оркестровку всего этого дела - у меня волосы шевелятся.