When I first started getting into Elixir, one thing that never quite made sense to me was the type system. It worked\u2026but it wasn\u2019t clear why it was set up the way it was or what benefits come from it. Hopefully, I can get you through some of my initial confusion about Elixir types.<\/p>\n
My initial confusion came from just trying to dive in after coming from other languages. When I started exploring Elixir, I wasn\u2019t quite clear on what made Elixir different or the tradeoffs in language design that facilitated those differences. I got into the nuts and bolts of those differences in my post about comparing Elixir and Go<\/a>, but I\u2019m going to cut to the chase regarding how it affects types first.<\/p>\n Take this example that initially just confused me:<\/p>\n This is a very simple and contrived example illustrating a tuple being used to define a function. Elixir uses pattern matching when the function is called, so if I call the function like so:<\/p>\n The result is that it will call the second function because it will match on There are also guard clauses<\/a> that can check the types at runtime, like so:<\/p>\n As a follow-up to that, why can\u2019t we define types in a JSON API? We can<\/em> define a type on either end, but everything is just going to be serialized to a string, sent over the wire, and then deserialized on the other end back into whatever type you\u2019ve defined.<\/p>\n That\u2019s an important detail when you consider that Elixir works using message passing. Elixir functions are set up so that they can transparently be called across processes, heaps, or even machines in a cluster. You might say you\u2019re sending some fancy, contrived type that you\u2019ve created, but underneath it all it\u2019s just a collection of basic data types with a name attached to it.<\/p>\n That\u2019s all those tuples are in this example. Here is my Because distributed computing transparently across nodes outside of a single heap space is critical to the functionality of Elixir, any more elaborate approach than this would involve serializing, passing, and deserializing for every function call before we even get into contract management.<\/p>\n Message passing is at the root of everything in Elixir, and it\u2019s critical to operating millions of isolated heaps across multiple machines. Those isolated heap spaces make extreme fault-tolerance possible since they can be killed and restarted without impacting other parts of the system.<\/p>\n These are our building blocks.<\/p>\n Wait\u2026what?<\/p>\n That was my reaction until I attended Jason Voegele\u2019s excellent Optimistic Type Checking<\/a> talk at ElixirConf this past September. If you have the time, it\u2019s worth a watch, but I\u2019m going to summarize with some of his excellent examples.<\/p>\n The example in the previous section looked like dynamic typing because we weren\u2019t doing anything with it. Elixir does actually have strict type checking between primitives.<\/p>\n In other languages, you might use a The Dialyzer<\/a> takes advantage of this by scanning your code and inferring types based on the operators used with them. Variables next to a plus can only be numbers, and so on. With this knowledge, Dialyzer can look through your code and identify instances where a variable is being passed a type that doesn\u2019t belong. Dialyzer works on compiled BEAM files and ships with Erlang, but it can be easily plugged into your Elixir project with Dialyxir<\/a> or Dialyze<\/a>.<\/p>\n The combination of pattern matching and Dialyzer will catch most of your type violations. You get strong typing and compile time type checking, which strikes a nice balance between the flexibility of dynamic types as well as the strictness of static types.<\/p>\n You may want more than those; implicit checks aren\u2019t always enough, and that\u2019s where typespecs<\/a> come in handy. Sometimes it\u2019s possible to create open-ended type definitions, and I\u2019ll use Voegele\u2019s example to demonstrate that here.<\/p>\n When declaring a pattern for a function with an unused variable, you leave the pattern open-ended. In these cases, you can define a typespec to explicitly declare the definition.<\/p>\n By adding that spec declaration, Dialyzer can now check every place in the code that the Typespecs work with all of the basic types: primitives, atoms, lists, maps, tuples, and even custom types<\/a>.<\/p>\n The end result here is that you get dynamic typing with implicit compile time type-checking by default. You can utilize runtime enforcement with guards, and you can explicitly check any questionable types with typespecs.<\/p>\n Immutable data makes verifying these easier while the adherence to message-passing-compatible structure makes distributed computing and transparent clustering possible. In other words, you gradually increase your type strictness in the same way that you gradually iterate on your development approach.<\/p>\n This approach is an excellent compromise that gives you the best of both worlds with dynamic and static typing, while avoiding the drawbacks of each.<\/p>\n Earlier in this post, I showed the string concatenation operator for sake of example, but that\u2019s not very efficient.<\/p>\n Raw string concatenation results in creating a new string from two other strings. This is inefficient because now our memory usage is the combination of both prior strings and the result. Erlang\u2019s secret weapon is to instead use IO Lists to pass and render arrays of string parts rather than combining them in memory.<\/p>\n If you want to go deep on this subject, the folks over at Big Nerd Ranch did a two-part blog post exploring the concept of IO.List<\/a>, as well as the implementation used within the Phoenix view layer<\/a> that makes its microsecond response times possible.<\/p>\n Those posts go into more detail and numbers than I will here, but picture this. You create a multilevel template within Phoenix. You\u2019ve got a layout, views, and smaller pieces, but intermixed with all of your code and variables are bits of HTML.<\/p>\n When Phoenix is compiled, those bits are separated into immutable pieces of memory\u2026once. Rendering a view and passing it back through to the requestor no longer becomes a task of outputting all of the combined HTML intermixed with the data. Instead this returns an array of memory references to pieces of HTML alongside the data that will fill those gaps.<\/p>\n When that array gets back to the socket, each piece is sent directly to the socket in proper order\u2026byte by byte\u2026without using any more RAM than it did after compilation. Iterating through a list surrounded by On the one hand, I felt a responsibility to include that; running off and doing string concats and explaining how the Dialyzer does it is great even though that particular case isn\u2019t efficient. On the other hand, knowing where that blazing Phoenix speed comes from is pretty cool\u2026and knowing is half the battle.<\/p>\ndef do_it({:starsky, do_what}), do: do_what\r\ndef do_it({:hutch, do_what}), do: do_what<\/pre>\ndo_it({:hutch, \"Something cool needs to be done here\"})<\/pre>\n:hutch<\/code>. My first thought in looking at that was simply, \u201cWhy not just create a :hutch<\/code> type? Why not a separate hutch function?\u201d<\/p>\ndef do_it({:starsky, do_what}) when is_binary(do_what), do: do_what<\/pre>\n:starsky<\/code> payload, and here is my :hutch<\/code> payload. As long as the rest of the structure matches the pattern of what\u2019s being passed in, it will call the appropriate function. If the structure doesn\u2019t match, the call will fail.<\/p>\nStrong, Dynamic, Gradual Typing<\/h2>\n
my_string = \"Bob\"\r\nmy_int = 5\r\nmy_string + my_int # This is an error<\/pre>\n
+<\/code> for concatenation of strings or addition. In Elixir, there is no operator overloading. You\u2019ll see a whole set of operators<\/a> that exist for different types.<\/p>\n1 + 1 # = 2 Math\r\n[1,2,3] ++ [4,5,6] # = [1,2,3,4,5,6] List concatenation\r\n\"foo\" <> \"bar\" # = \"foobar\" String concatenation<\/pre>\n
def add(x, y), do: x + y\r\n # add(number, number) :: number\r\n\r\ndef divide(x, y), do: x \/ y\r\n # divide(number, number) :: float\r\n\r\ndef and(false, _), do: false\r\ndef and(_, false), do: false\r\ndef and(true, true), do: true\r\n # and(any, any) :: boolean<\/pre>\n
@spec and(boolean, boolean) :: boolean\r\ndef and(false, _), do: false\r\ndef and(_, false), do: false\r\ndef and(true, true), do: true<\/pre>\n
and\/2<\/code> function is called to ensure that Booleans are being passed for both arguments and that what\u2019s being returned is also a Boolean. This job is made a lot easier because of immutable data; it doesn\u2019t have to worry that a string it checked will be reassigned an integer later on.<\/p>\nThis is gradual typing<\/h3>\n
Efficient Usage<\/h2>\n
\"<li>\"<\/code> and \"<\/li>\"<\/code>? Each of those parts is a single memory reference no matter how many list items you combine.<\/p>\n