Как стать автором
Обновить

Комментарии 12

НЛО прилетело и опубликовало эту надпись здесь

Да это и в Akka тоже реализовано из коробки, тогда уж целесообразнее на scala это писать. На совсем новой экосистеме наш проект делать было бы довольно затратно — все-таки у erlang философия сильно отличается от Java (на мой взгляд).

НЛО прилетело и опубликовало эту надпись здесь

"(Any) -> Any?" как-то хреново выглядит для статически типизированного языка

Я подозреваю, что это частично связано с тем, что там внизу Java, частично с тем, что потенциально будет проблемно построить иерархию сообщений/ответов — ведь есть еще служебные сообщения и сообщения жизненного цикла.


Если посмотреть в реализацию актора, возврат там вообще только проверяется на null и все.


Но выглядит не очень, согласен.

не смотрели в сторону kotlinx.coroutines? там есть реализация акторов

Смотрел, но на тот момент (kotlin 1.0.6) они были в зачаточном состоянии, и пришлось бы акторы реализовать самостоятельно.

Саму модель реализовать не зашкаливающе сложно, да. Однако чтобы это еще и быстро работало (читай, легковесные треды) и учесть крайние случаи — уже достаточно трудозатратно. Ну и писать свой велосипед тоже как-то не очень...

Чтобы быстро работало, надо избегать тредов, даже легковесных, и ограничиваться Runnable на Executor'ах.
Какие такие крайние случаи затратно учитывать, не могу себе представить по недостатку опыта. Не могли бы вы поделиться?

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

Поясните пожалуйста, что значит избегать тредов? Executor разве не с тредами работает? ) Чтобы быстро работало надо как раз и считать задачи в Executor'ах на реальных тредах. А там где требуется наплодить много паралелльных задач, то берём модель акторов и такая модель будет медленнее пула на реальных тредах.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий