From Elixir to Akka (and back) - ElixirConf Mx 2017

Slides from my talk at ElixirConf Mx 2017. Mexico City

Transcript

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 actors 1 2 Overrides and all the Java/Scala stuff 2 3 Must explicitly create actor system 3 4 Actor creation 4
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…
48. Thank you! Agustín Ramos @MachinesAreUs