Recommended
Recommended
More Related Content
Similar to A Sip Of Elixir
Similar to A Sip Of Elixir (20)
More from OnorioCatenacci
Recently uploaded
Recently uploaded (20)
A Sip Of Elixir
- 1. A Sip Of Elixir with apologies to Josh Adams PghTechFest 2014
- 2. Who Am I? Software Engineer - Quicken Loans @OldDutchCap #pghtechfest Catenacci@ieee.org
- 3. My Goal What Do I Want To Get From This Talk?
- 4. Erlang
- 5. Lots of APE (Asynchronous Phone Equipment)
- 6. Erlang (cont’d.) ● Fault tolerant ● Agent based ● High Scalability ● Code Hot Patch
- 7. Lots of data stores
- 8. Data Can Be Passed In Parallel AA111 AA112 AA113 AA121 BA100
- 10. Along Came Jones
- 12. Protocols
- 13. A Little Look At Code
- 14. Other Aspects Of Elixir ● Mix ● Documentation Everywhere
- 15. Why Not Elixir? ● Too much for some jobs ● Sort of new
- 16. You must remember this Elixir and Erlang similar Elixir adds metaprogramming Elixir adds protocol-based polymorphism
- 17. More Info ● http://www.elixir-lang.org ● http://www.elixirsips.com ● https://groups.google.com/forum/#!forum/elixir-lang-talk ● http://www.meetup.com/DaytonElixir/
- 18. Credits Brick Wall by Emily Haasch from The Noun Project Database by Romeo Barreto from The Noun Project Handshake by Pavel Pavlov from The Noun Project
Editor's Notes
- At the end of this next hour we’ll all be 1 hour older. My goal is that all of you will be one hour older and a bit smarter about what Elixir is and how to find out more about it if you think it’s worth your while. I’m telling you my goal so you can tweet “Yep, Onorio met his goal” or “Onorio met his goal? Not so much” Telling you my goal for this talk makes me a bit more accountable to you as far as what you get out of this.
- So in order to understand Elixir, one must first understand Erlang. Erlang was developed by Ericsson as a way of programming phone switches. When you understand this basic reality a lot of the design choices which were made in creating Erlang are very easy to understand. This is not to say that Erlang is some sort of glorified domain specific language; it is to say that some of the design decisions made in creating Erlang were informed by this reality.
- The thing is that prior diagram was a little bit deceptive. Two phone switches talking to each other isn’t really all that tough to do in the grand scheme of things. Lots of phone switches talking to each other--that’s a whole new ballgame. Plus, a growing business may want to have more customers because after all customers give the business money and businesses usually like getting money. So being able to add even more switches without having to endure a major re-write of the software would also be a good design goal as well. You’ll note that in this diagram not all of the phone icons are connected; I deliberately simplified the diagram to keep it from being too busy.
- So the purpose for which Erlang was built informed several decisions about how Erlang was designed. Erlang was designed with fault tolerance as one of its design goals. Imagine what would happen if one phone switch going out cascaded to other phone switches. Likewise, because each phone switch must be able to act independent of other phone switches, Erlang has a strong agent based model built in. And, again, due to its origins high scalability was a design goal right from the start. Erlang also has a feature that’s somewhat uncommon--at least among languages which run anywhere other than mainframes. Erlang has the ability to hot patch code.
- It’s not hard to make the mental leap from passing data or phone calls between phone switches and passing data between data stores. I use the term “data store” very intentionally. The data stores could be databases or they could be people communicating via IM. In a sense, it’s immaterial to the underlying software and in another very real sense the same kinds of problems come up in all three scenarios.
- It’s also important to note that even for a single source and a single target we can do things in parallel. So imagine I had a list of codes I needed to validate against a database. If each check is independent of any other check we can do all these checks in parallel. That is, they can all be run at the same time because the result of one check will not change the result of another. Of course this would be impacted by business rules but in a good many cases, it’s fine to run the checks in any order you care to as long as you have some way of knowing which data still needs to be validated. And it’s not a large leap from checking data to recording data.
- But Erlang by itself is not the whole story. Erlang apps are built on a very special VM called the BEAM. The BEAM is, to some extent, the secret sauce of Erlang because it makes it trivial to spin up secondary and tertiary and even higher n-ary processes each isolated and separate. It’s also important to recognize that the processes we’re discussing here are not OS level processes. OS level processes tend to be pretty heavy weight; these processes are much less resource intensive. In fact someone once asked Joe Armstrong, one of the co-creators of Erlang about porting the language to java; a project called Erjang. He said he didn’t think it would get anywhere because there are features in the BEAM VM which simply support concurrency far better. The point is that Erlang and the BEAM VM together are (sort of) greater than the sum of the parts.
- Actually, along came Jose; and Jose didn’t come along right away. Erlang was first created in 1986 and it was open-sourced in 1998 by Ericsson. Because the concurrency and scaling in Erlang is hard to beat lots of systems that need high scale are built with Erlang. So Jose was creating code with the BEAM VM code and he found there were a few things that he wanted that just weren’t there. Coming from Ruby, he wanted polymorphism and he wanted true metaprogramming. Of course, being a main committer for Ruby when Jose decided to build a new language he borrowed freely from Ruby’s syntax.
- The use of meta-programming or “macros” as they’re commonly called by software developers is very much part of Elixir. Most of Elixir was built as macros around a very small core of concepts. Defmodule, Defproc and if among other things are implemented as macros. I’ll discuss those first two items a little more in depth but I trust that most people sitting here are familiar with the concept of a logical test in a programming language.
- So besides meta-programming Elixir implements polymorphism in two ways. First with multiple function clauses and secondly with protocols. So, what is a protocol? A protocol is a way of specifying certain behavior that we want present in a module. For instance if we wanted to insure that the class represented by a module were sortable we might say the module implements “Sortable” However, since the modules don’t really carry data with them
- So why would I not use Elixir? There are a few reasons: 1.) If I don’t need high-throughput, high scalability solutions, it’s a bit of mental tax to pay that I’d rather not pay. It’s a question of picking the right tool for the job. If I’m building an earthen dam then I would love to have a bulldozer. But if I’m building a sandcastle a bulldozer doesn’t help and, in fact, can be a bit of a hindrance. 2.) The other thing to keep in mind is that Elixir is somewhat new. It’s still be solidified and stabilized as we speak. I wouldn’t let that keep me from looking at it; I would bear that fact in mind if I’m building a production system that my business will rely upon.