From Elixir to Akka (and back) - ElixirConf Mx 2017
1 like1,413 views
From Elixir to Akka (and back) The document compares the Actor Model as implemented in Elixir and Akka. It discusses key differences in how messages are passed, mailboxes are handled, scheduling works, and monitoring capabilities between the two frameworks. It ultimately concludes that Akka adds unnecessary complexity on top of the JVM compared to Elixir's cleaner implementation of the Actor Model.
![import akka.actor.Actor
import akka.actor.ActorSystem
import akka.actor.Props
class HelloActor extends Actor {
def receive = {
case "hello" => println("hello back at you")
case _ => println("huh?")
}
}
object Main extends App {
val system = ActorSystem("HelloSystem")
val helloActor = system.actorOf(Props[HelloActor],
name="helloactor")
helloActor ! "hello"
helloActor ! "buenos dias"
}
1
Classes, objects.. and actors1
2
Overrides and all the Java/Scala stuff2
3
Must explicitly create actor system3
4
Actor creation4](https://image.slidesharecdn.com/elixirconfmx-2017-fromelixirtoakka-171121171815/85/From-Elixir-to-Akka-and-back-ElixirConf-Mx-2017-8-320.jpg)
From Elixir to Akka (and back) - ElixirConf Mx 2017
- 1. From Elixir to Akka (and back) Agustín Ramos @MachinesAreUs
- 2. Why?
- 3. Actors? The Actor Model Hewitt, Meijer and Szyperski, 2012
- 4. Actor Model Actor A Actor B • Asynchronous messaging • Concurrent execution • No shared state (memory) Message Mailbox
- 5. Image from “Learn you some Erlang for a Great Good”
- 7. hello_process = spawn fn -> receive do "hello" -> IO.puts "hello back at you" _ -> IO.puts "huh?" end end send hello_process, "hello"
- 8. import akka.actor.Actor import akka.actor.ActorSystem import akka.actor.Props class HelloActor extends Actor { def receive = { case "hello" => println("hello back at you") case _ => println("huh?") } } object Main extends App { val system = ActorSystem("HelloSystem") val helloActor = system.actorOf(Props[HelloActor], name="helloactor") helloActor ! "hello" helloActor ! "buenos dias" } 1 Classes, objects.. and actors1 2 Overrides and all the Java/Scala stuff2 3 Must explicitly create actor system3 4 Actor creation4
- 9. Language
- 10. Mailboxes
- 11. • Message passing is done by copying. • There’s only one type of mailbox, and it’s part of the actor. • No mailbox size limit. • Only physical limitations. • A process receives a message when it extracts it from the mailbox. • Order or reception is imposed by the receiving process.
- 12. • Message passing is done by reference. • You can change the message once it has been sent! • The mailbox is a different entity from the actor. • There are several out-of-the-box implementations of a mailbox. • Order of reception is determined by the semantics of the mailbox implementation.
- 13. • Builtin mailbox implementations • UnboundedMailbox (default) • SingleConsumerOnlyUnboundedMailbox • NonBlockingBoundedMailbox • UnboundedControlAwareMailbox • UnboundedPriorityMailbox • UnboundedStablePriorityMailbox • BoundedMailbox • BoundedPriorityMailbox • BoundedStablePriorityMailbox • BoundedControlAwareMailbox
- 15. Why?
- 16. Scheduling
- 17. • Erlang is a soft real time platform. • This means: • Preemptive scheduling. • No process can block other processes. • There are several schedulers (usually 1/processor). • Criteria for scheduling/preempting a process: • Priority • Reductions
- 18. class PrintActor extends Actor { def receive = { case i: Int => println(s"PrintActor: ${i}") } } Blocking class BlockingFutureActor extends Actor { implicit val executionContext: ExecutionContext = context.dispatcher def receive = { case i: Int => println(s"Calling blocking Future: ${i}") Future { Thread.sleep(5000) //block for 5 seconds println(s"Blocking future finished ${i}") } } }
- 19. val actor1 = system.actorOf(Props(new BlockingFutureActor)) val actor2 = system.actorOf(Props(new PrintActor)) for (i <- 1 to 100) { actor1 ! i actor2 ! i } Blocking When you run this code, it get’s stuck around PrintActor: 44 PrintActor: 45
- 20. • Every actor runs within ‘Dispatcher’ threads. • If you block a dispatcher thread, you risk blocking the whole system.
- 22. Esas ambigüedades, redundancias y deficiencias recuerdan las que el doctor Franz Kuhn atribuye a cierta enciclopedia china que se titula Emporio celestial de conocimientos benévolos. En sus remotas páginas está escrito que los animales se dividen en (a) pertenecientes al Emperador, (b) embalsamados, (c) amaestrados, (d) lechones, (e) sirenas, (f) fabulosos, (g) perros sueltos, (h) incluidos en esta clasificación, (i) que se agitan como locos, (j) innumerables, (k) dibujados con un pincel finísimo de pelo de camello, (1) etcétera, (m) que acaban de romper el jarrón, (n) que de lejos parecen moscas. El idioma analítico de John Wilkins Jorge Luis Borges, 1952
- 23. Why?
- 24. Tooling
- 25. Build Tool
- 26. Mix • Bundled with Elixir • Easy setup • Fast • Doesn’t get in your way
- 27. • Super slow • It’s not only because of the Scala compiler. • You can run it as a server. • But, once you run an application runs, the only way to stop it is to kill the whole JVM. • Multi-projects: • I don’t recommend using it. • Slows the build way further.
- 28. Why?
- 29. Monitoring
- 31. • Lightbend monitoring (paid service). • Couldn’t get even a screenshot without engaging with sales department. • No money? Visual VM. • Not enough for peeking into an actor system.
- 32. Versions
- 33. What’s my ultimate thought about Akka?
- 34. It’s a trap!
- 35. A (very dark) Software Trend…
- 37. Common Practice (Almost) Non-Existent Practice Dependency Injection
- 38. Dependency Injection “Ignoring the imbecilic name, I think that if you’re stuck with a mainstream language, that may be a reasonable work around. It requires a significant degree of preplanning, and makes your application dependent on one more piece of machinery that has NOTHING to do with the actual problem the application is trying to solve. On the positive side, it helps guarantee employment for software engineers. That said, it’s important to understand that DIFs are just a work around for a deficiency in the underlying language.” Constructors Considered Harmful Gilad Bracha http://j.mp/ccharmful
- 39. • C: It’s too slow! • A: Run it as a server! • C: It’s still very slow • Here you are some plugins to profile your build!
- 40. • Na concurrent, yo? Na’ problem! • Na scale, yo? Na’ problem! • Ya’ idiot, yo?…
- 41. The Mess We’re In Joe Armstrong, 2014
- 42. Is it really "Complex"? Or did we just make it "Complicated"? Alan Kay, 2013
- 43. Standard Akka Application Stack JVM Standard Libraries 3rd Party Java Libraries Scala Scala Standard Libraries Akka Core Akka Extensions Your Application Code Complex Complex Super Complex ???
- 44. The trend is to try to alleviate technology deficiencies by means of adding complexity.
- 45. … Instead of stepping back and fixing them from first principles.
- 46. Let it go…