С выпуском Scala 2.9.0 также был объявлен стек типов безопасности, который сочетает в себе язык Scala с инфраструктурой Akka. Теперь, хотя Scala имеет участников в своей стандартной библиотеке, Akka использует свою собственную реализацию. И, если мы ищем другие реализации, мы также обнаружим, что у Lift and Scalaz также есть реализации!
Итак, в чем разница между этими реализациями?
Этот ответ на самом деле не мой. Он был выпущен Виктором Клангом (известность Акка) с помощью Дэвида Поллака (славы Поднимания), Джейсона Заугага (славы Scalaза) Филипп Халлер (из Scala Актеры славы).
Все, что я делаю здесь, это его форматирование (что было бы проще, если бы поддерживаемые Qaru таблицы).
Есть несколько мест, которые я буду заполнять позже, когда у меня будет больше времени.
Актеры Scalaz
Минимальная сложность. Максимальная общность, модульность и расширяемость.
Актеры-актеры
Минимальная сложность, сбор мусора JVM, а не беспокойство о явном жизненном цикле, поведение обработки ошибок, совместимое с другими программами Scala и Java, легкий/небольшой объем памяти, почтовый ящик, статически похожий на Scala актеров и актеров Erlang, высокая производительность.
Scala Актеры
Обеспечьте полную модель актера Erlang в Scala, легкий/небольшой объем памяти.
Актеры Акка
Простая и прозрачно распределяемая, высокопроизводительная, легкая и легко адаптируемая.
Scalaz Actors Lift Actors Scala Actors Akka Actors Current stable ver. 5 2.1 2.9.0 0.10 Minimum Scala ver. 2.8 2.7.7 2.8 Minimum Java ver. 1.5 1.5 1.6
Scalaz Actors Lift Actors Scala Actors Akka Actors Spawn new actors Yes Yes Yes Yes inside of actor Send messages to Yes Yes Yes Yes known actor Change behavior Actors are Yes Yes: nested Yes: for next message immutable react/receive become/unbecome Supervision Not provided No Actor: Yes, Yes (link/trapExit) Reactor: No
Если пользователь определяет общедоступные методы их Актеры, они могут быть снаружи?
Actor[A] extends A => ()LiftActor, SpecializeLiftActor[T]Reactor[T], Actor extends Reactor[Any]Actor[Any] Scalaz Actors Lift Actors Scala Actors Akka Actors
Manual start No No Yes Yes
Manual stop No No No Yes
Restart-on-failure n/a Yes Yes Configurable per actor instance
Restart semantics n/a Rerun actor Restore actor to stable state by re-allocating it and
behavior throw away the old instance
Restart configurability n/a n/a X times, X times within Y time
Lifecycle hooks provided No lifecycle act preStart, postStop, preRestart, postRestart
Scalaz Actors Lift Actors Scala Actors Akka Actors
Fire-forget a ! message actor ! msg actor ! msg actorRef ! msg
a(message)
Send-receive-reply (see 1) actor !? msg actor !? msg actorRef !! msg
actor !! msg
Send-receive-future (see 2) actor !! msg actorRef !!! msg
Send-result-of- promise(message). future.onComplete( f => to ! f.result )
future to(actor)
Compose actor with actor comap f No No No
function (see 3)
(1) Любая функция f становится таким актером:
val a: Msg => Promise[Rep] = f.promise
val reply: Rep = a(msg).get
(2) Любая функция f становится таким актером:
val a = f.promise
val replyFuture = a(message)
(3) Контравариантный функтор: actor comap f. Также композиция Клейсли в Promise.
TBD
Scalaz Actors Lift Actors Scala Actors Akka Actors reply-to-sender-in-message reply-to-message
Поддерживает вложенные запросы?
TBD
Scalaz Actors Lift Actors Scala Actors Akka Actors Name for Execution Mechanism Execution Mechanism is configurable Execution Mechanism can be specified on a per-actor basis Lifecycle of Execution Mechanism must be explicitly managed Thread-per-actor execution mechanism Event-driven execution mechanism Mailbox type Supports transient mailboxes Supports persistent mailboxes
Scalaz Actors Lift Actors Scala Actors Akka Actors
Transparent remote n/a No Yes Yes
actors
Transport protocol n/a n/a Java Akka Remote Protocol
serialization (Protobuf on top of TCP)
on top of TCP
Dynamic clustering n/a n/a n/a In commercial offering
TBD
Scalaz Actors Lift Actors Scala Actors Akka Actors Define an actor Create an actor instance Start an actor instance Stop an actor instance
scala.actors была первой серьезной попыткой реализовать стиль concurrency стиля Erlang в Scala, который вдохновил других разработчиков библиотек на улучшение (в некоторых случаях) и более реалистичные реализации. Самая большая проблема (по крайней мере для меня) заключается в том, что в отличие от процессов Erlang, дополненных OTP (что позволяет создавать отказоустойчивые системы), scala.actors предлагают хорошую основу, набор стабильных примитивов, которые должны использоваться для построения более высокоуровневых рамок - в конце дня вам придется писать собственные супервизоры, каталоги актеров, конечных автоматов и т.д. наверх актеров.
И здесь Akka приходит на помощь, предлагая полнофункциональный стек для актерской разработки: более идиоматические актеры, набор абстракций высокого уровня для координации (балансировщики нагрузки, актер пулы и т.д.) и создание отказоустойчивых систем (супервизоры, перенесенные из OTP и т.д.), легко настраиваемые планировщики (диспетчеры) и т.д. Извините, если я говорю грубо, но я думаю, что не будет слияния в 2.9.0+ - Id скорее ожидают актеров Akka, чтобы постепенно заменить реализацию stdlib.
Scalaz. Обычно у меня есть эта библиотека в списке зависимостей всех моих проектов, и когда по какой-то причине я не могу использовать Akka, неблокирующий Scalaz Promises (с вся доброта, как sequence) в сочетании со стандартными актерами, спасает день. Однако я никогда не использовал актеров Scalaz вместо замены scala.actors или Akka.
Актеры: Scala 2.10 против Akka 2.3 против Lift 2.6 vs Scalaz 7.1
тестовый код и результаты для средней латентности и пропускной способности на JVM 1.8.0_x.