С выпуском Scala 2.9.0 был также анонсирован Typesafe Stack, который объединяет язык Scala с фреймворком Akka. Теперь, хотя в стандартной библиотеке Scala есть акторы, Akka использует собственную реализацию. И, если мы поищем другие реализации, мы также обнаружим, что у Lift и Scalaz тоже есть реализации!
Итак, в чем разница между этими реализациями?
На самом деле это не мой ответ. Он был спродюсирован Виктором Клангом (прославившимся Akka) с помощью Дэвида Поллака (от Lift), Джейсона Заугга (от Scalaz), от Филиппа Халлера (от Scala Actors).
Все, что я здесь делаю, это форматирую (что было бы проще, если бы Stack Overflow поддерживал таблицы).
Есть несколько мест, которые я заполню позже, когда у меня будет больше времени.
Скалаз Актеры
Минимальная сложность. Максимальная универсальность, модульность и расширяемость.
Лифт-актеры
Минимальная сложность, сборка мусора с помощью 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 был первой серьезной попыткой реализовать параллелизм в стиле Erlang в Scala, которая вдохновила других разработчиков библиотек на создание лучших (в некоторых случаях) и более производительных реализаций. Самая большая проблема (по крайней мере для меня) заключается в том, что в отличие от процессов Erlang, дополненных OTP (который позволяет создавать отказоустойчивые системы), scala.actors предлагает только хорошая основа, набор стабильных примитивов, которые необходимо использовать для построения более высокоуровневых фреймворков - в конце концов, вам придется писать свои собственные супервизоры, каталоги акторов, конечные автоматы и т. д. актеров.
И здесь на помощь приходит Akka, предлагающий полнофункциональный стек для разработки на основе акторов: больше идиоматических акторов, набор высокоуровневых абстракций для координации (балансировщики нагрузки, пулы акторов и т. Д.) И построение отказоустойчивых систем (супервизоров, портированных с OTP и т. д.), легко настраиваемых планировщиков (диспетчеров) и т. д. Извините, если я покажусь грубым, но я думаю, что в 2.9.0+ не будет слияния - я бы скорее ожидал, что акторы Akka постепенно заменят реализацию stdlib.
Скалаз. Обычно у меня есть эта библиотека в списке зависимостей всех моих проектов, и когда по какой-то причине я не могу использовать Akka, неблокирующий Scalaz Promises (с все добра, вроде sequence) в сочетании со стандартными актерами спасают положение. Однако я никогда не использовал акторы Scalaz вместо scala.actors или Akka.
Актеры: Scala 2.10, Akka 2.3, Lift 2.6, Scalaz 7.1
Тестовый код & results для средней задержки и пропускной способности на JVM 1.8.0_x.
