Кажется, дожидаться ответа сообщения нельзя (или про это нет в туториале)

Как вообще тогда работает I/O — не знаю

Ну тебе в ответ видимо прилетает месседж.

Ну разве что ты передаёшь туда себя, чтобы тебе могли ответить
Но это, типа, будет очень бойлерплейтно

Ну, Go way, все дела

Но видимо так и есть
Например, InputStream принимает на вход что-то, что реализует интерфейс InputNotify, который может получить какую-то инфу

Но это ж неюзабельно

Плюс размазывать логику операции по нескольким хэндлерам/состояниям будет неудобно.

Типа... пишите всё явными стэйт-машинами и не вымахивайтесь.

Но вся стдлиба явно сделана именно через передачу нотифаеров везде

Ну, даже с нотифаями дедлок возможен, просто неявный. Мы сместили место ошибки в другое место.

Что такое «неявный дедлок»?

Хм... логический что ли...

Актора А отправляет месседж1 актору Б и для продолжения процесса нам надо чтобы он от Б получил месседж2. Актору Б для того чтобы отправить месседж2 актору А, нужно от него ещё получить месседж3. Но А отправляет месседж3, только когда получит месседж2.

Типо да, ничего не лочится в традицинном смысле этого слова, но процесс зависнет и не будет продолжаться ожидаемым образом. Своеобразный дедлок условий никуда не делся.

Думаю именно подобные моменты Алекс подразумевал, что это логическая ошибка.

Процесс при этом тупо завершится, кажется

Актор А отправляет м1
Актор Б получает м1 и сохраняет куда-то себе (он не может в явном виде ждать месседжа)
Актор А не выполняет ничего
Актор Б не выполняет ничего
Все акторы ничего не делают, программа завершается

Завершение процесса is arguably better than deadlocking

Как это актор не может в явном виде ждать месседжа? Откуда он может знать кто ему что там и когда будет отправлять? А если сообщение на обработку прийдёт через 5 минут?

Допустимые «сообщения» для отправления актору определяются как методы ключевым словом be

#мне_поебать_на_уб

Актор всегда ждёт сообщений и обрабатывает свой мейлбокс в порядке их получения