Мне видится, что модель акторов
1) Решает проблемы гонок, которых не может быть по определению (актор обрабатывает одно сообщение за раз) и видимости
2) прозрачный переход от локального исполнения, когда все общение происходит в рамках одного процесса, к межпроцессорному(ну или с малой кровью). А это межпроцессорное взаимодействие может происходить в рамках одной машины или же в рамках нескольких машин.

Модель акторов это интересный топик, но освещается как-то однобоко. За последние несколько лет много все просмотрел и прочитал по теме, но все эти обсуждения были в стиле саксэс стори, которые повторяли из раза в раз одни и тоже банальности - мантры "не используйте треды с локами, используйте только акторов", "вы забудете о дедлоках", а также прочие доводы в стиле Капитана Очевидность.

Но остаются вопросы, которые не освещаются (или освещаются, но в кулуарах, когда кругом все свои). Оставив все вопросы производительности (т.к. очевидно, что общение решение всегда проигрывает тому, что написано под конкретный случай), и всяких законов Мура, когда эту модель лучше/проще/легче не использовать? Какие есть проблемы и подводные камни всплывают при ее использовании?

Согласен во всем.

Но насколько в реальной жизни модель акторов будет удобней? Мне кажется, что даже при всех ее достоинствах, это не так все просто. Поясню.
Модель акторов позволяет создавать огромные зубодробительные конечные автоматы о которых как-то там можно думать (и этот процесс будет несколько легче чем с тредами и локами). Но востребованы ли они в практическом программировании?
Просто есть очень большая вероятность того, что на реальном проекте в итоге любая система акторов будет упрощаться до тех пор пока она не будет представлять из себя другую систему, которая разбита на меньшие подсистемы aka модули, которые общаются между собой самым простейшим способом, устранив тем самым сложные переходы между некоторыми состояниями. И это будет сделано для того, чтобы программу проще тестировать, поддерживать, добавлять новый функционал и проч.

Т.е. фактически в результате будет несколько модулей, которые общаются через заданные интерфейсы. Но ведь тоже самое будет проделано с системой, которая строится на локах с тредами и компанией! И ее модули скорее всего также будут общаться средствам сообщений.

Это все к тому, что акторы и текущая парадигма спокойно могут жить вместе - акторы контролируют глобальные переходы между состояниями и взаимодействие между модулями, а внутри модулей стандартные локи и прочие подобные примитивы.

p.s.
Интересный пейпер по тематике акторов в scala, затрагивающий тему смешения парадигм.
Why Do Scala Developers Mix the Actor Model with Other Concurrency Models?

ZyK_BotaNschwaНо востребованы ли они в практическом программировании?
да

schwaПросто есть очень большая вероятность того, что на реальном проекте в итоге любая система акторов будет упрощаться до тех пор пока она не будет представлять из себя другую систему, которая разбита на меньшие подсистемы aka модули, которые общаются между собой самым простейшим способом, устранив тем самым сложные переходы между некоторыми состояниями.
как вы эту вероятность рассчитали? как по мне - так чушь.
schwaТ.е. фактически в результате будет несколько модулей, которые общаются через заданные интерфейсы. Но ведь тоже самое будет проделано с системой, которая строится на локах с тредами и компанией! И ее модули скорее всего также будут общаться средствам сообщений.
нет, все совсем не так.
schwaЭто все к тому, что акторы и текущая парадигма спокойно могут жить вместе - акторы контролируют глобальные переходы между состояниями и взаимодействие между модулями, а внутри модулей стандартные локи и прочие подобные примитивы.
глупость.
Хорошо аргументируешь.
99 % процентов реальных приложений именно так и работают. Message-passing используется в любом мало-мальски нормальном приложении (может быть внутри одного процесса он используется очень мало т.к. есть работаюшие альтернативы), а в сообщении между процессами вполне.
К тому же раз ты не утруждаешь себя написать хоть один аргумент к использованию акторов кроме как чушь и проч., то я напишу это сам какой плюс могут дать акторы реальному программисту на реальном проекте, а не хипстеру, который выучит ерланг и хаскель за неделю, и потащит их в продакшен.

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