Приватность там нужна только чтобы кто-то не делал smth.self

Видимо, придется жить с такой возможностью

Ну да, в этом вроде нет страшного ничего

Если не будет актора, для интеграции можно использовать stateless синхронные вызовы, либо локально, либо через RPC. Очереди в качестве точки интеграции без необходимости длительного хранения данных вообще решение не очень.
Про перфоманс пруфов дать не могу, у меня есть только мнения тех, кто плотно работал с акторами.

Актор может не хранить Стэйт. За ним может быть пул акторов который и реализует rpc вызовы и обработку ответов и прочего

Интеграция чего с чем? Синхронный вызов к чему?  Мы какой-то частный случай рассматриваем?  Про очереди я говорил о конкаренси примитивах, а не внешних сервисах, и в качестве примера (как это сделано в статье Akka vs ZIO vs Monix по ссылке выше)

Система акторов очень похожа на систему микровервисов, связанных через очереди. И проблемы те же самые.

А что в этой аналогии является монолитом тогда?)

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

В типичной "опердени" как это принято называть. Обычный вызов включается в себя взаимодействие с каким-то глобальным состоянием, запросы в СУБД, и запросы в несколько внешних бэкендов. В принципе СУБД можно отнести к одному из них.
Чем больше таких игроков, тем более заметен описываемый эффект

Когда у вас в коде:
-  Много ветвлений
-  Есть локально-используемые ресурсы
-  Есть контекст
Разница в отладке и написании лично для меня становится слишком заметной

Потому что в акторах :
- Ветвление - это выбор куда послать, а куда не посылать сообщение, после первого сообщения понять на уровне кода, в какой из логических веток происходит обработка промежуточного сообщения довольно сложно.
- Скоупы использования ресурсов использовать тоже сложно. Фактически единственный вменяемый способ - создавать актора - владельца ресурса, и всех пользователей создавать внутри этого актора. Супервайзинг внешних ему акторов ставится трудным, иногда непреодолимо
- Контекста у сообщения по умолчанию нет. Фактически весь необходимый контекст нужно дописывать в посылаемое сообщение и пересылать дальше. Это значит либо много бойлерплейта, либо много абстракций гораздо более сложных, чем монады, поверх бихейвиоров, либо какой-то свой специальный фреймворк поверх всей акторсистемы, ни одного примера которого я не видел.

Но Сергей правильно сказал https://t.me/scala_ru/281850
Актор системы - абстракция, которая вас фактически спускает до уровня распределённых приложений с системой контроля фейлов и локальными гарантиями порядка. Лично для меня даже учитывая наличие контроля фейлов и локального порядка всё равно слишком сложная среда для рассуждений

А нету у вас примеров на которых видна разница? Типичные опердени чаще вообще без стейта, тут случай хитрее должен быть.
"- Скоупы использования ресурсов использовать тоже сложно."
"- Контекста у сообщения по умолчанию нет."
Скоуп ресурсов это каких например? И какой контекст имеется ввиду?

"Актор системы - абстракция, которая вас фактически спускает до уровня распределённых приложений"
Да, она слишком низкоуровневая. С другой стороны если нету сложной логики, вроде нормально выглядит

Низкоуровневая это с какой стороны ?

С точки зрения абстракций, посылаешь-ждешь все возможности

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

А если юзать акку и сервисы? Акку, где это реально нужно, и обыкновенную stateless scala где этого достаточно?

вся эта посылка сильно высокоуровневая, от тебя скрыты очереди и роутинг и все прочее

акка - динамически масштабируемые сервисы для всяких там кластеров/облаков, ну и если концепция акторов нравится, то для любого сервиса

Нет, не для всего