I thought I should write a post on the steps I took to learn Elixir. The name of this blog is Learning Elixir and I should devote a few more posts to broader learning.
I started out with Elixir not much more than a year ago in an attempt to broaden my skills. I’ve spent many years writing device drivers but want to branch out into other topics in software engineering. Distributed computing seemes interting to me and Elixir looks like an excelent language for that field.
Programming Elixir
The first resource I looked at was the elixir-lang.org getting started pages. This is a great guide and I still refer back to it often for the right syntax for constructs I haven’t internalized yet. The case special form is one in particular that I find my self going back to look up over and over. I read through the pages and examples. But the first few times through it didn’t stick.
The next resources I went to was was Dave Tomas’ Programming Elixir. I really enjoyed this book. Part I introduced me to Elixir syntax and tooling and helped me to start undestanding functional programming and pattern matching.
I like the parse and transform model of programming that Dave Tomas promotes in the book. This structure feels natural to me. In fact, I’ve approached writing code this way in the past. For me, it was in C, but this works in any language (though it may go against the grain in some).
Part II goes into concurrent programming. This was hard for me to grasp when I first read it. I still needed more experience with the core of the language. I returned to the section later on and took away much more. I suspect, I’ll return to this section again and again.
Functional Programming in Elixir
After reading Programming Elixir I turned to a strange resource: Functional Programming in Scala by Paul Chiusano and Rúnar Bjarnason. A Scala book? Yes, at this point I wasn’t completely sold on Elixir. But I was pretty convinced that I needed to learn more about functional programming. The book Functional Programming in Scala came highly recommended by several sources so I started working through it. I ended up doing many of the exercises in both Scala and Elixir. I ] eventually stopped working in Scala and focused on functional programming in Elixir.
I spent a lot of time reading through this book and working through the exercises and learned the basics of functional programming. Including how to use and implement functions like map and fold, how to compose higher order functions, and the value of a type system. All of this carried over to Elixir.
Well, not everything carried over to Elixir because Scala and Elixir have different semantics. One big example is in error handling. Functional Programming in Scala describes a system for managing errors and carring them through longer computations - railway oriented programming. You can use this system in Elixir, though the question is, should you? Railway oriented programming is a comprehensive system for handling errors at the local level. But, Elixr draws from the Erlang tradition of “let it crash” in which errors are treated as fatal exceptions at the local level and pushed up the supervisor tree to be handled in a holistic way. Both are valid options, railway oriented programing can be implemented in Elixir but it doesn’t integrate with all the existing tradition and technology that makes Elixir great.
Learning Elixir - the blog
I actually started this blog at about the same time that I started working through Functional Programming in Elixir. I realized that learning and teaching go hand in hand. That as you learn something the best way to solidify that knowledge is to explain it to someone else. So, I decided to start the “Learning Elixir” blog to give myself a place to reexplain what I had learned both to help myself solidify my newly gained knwledge and in the hopes that it would be helpful to others. The first dozen or so posts on this blog describe my attempts and answering the exercises in Functional Programming in Scala.
I think that writing this blog has been one of the best things I decided to do in order to motivate myself to learn Elixir. The blog holds me accountable to writing sometihng interesting about Elixir (almost) every week. To do this, I’ve worked on several projects and have read through a lot of Elixir code.
In fact, the Learning Elixir blog is so central to my learning process that the rest of this post has really just turned into a list of old posts with my thoughts on how these posts and projects have taught me to be a better Elixir programmer.
ElixirConf 2014
I attended ElixirConf in Austin in July of 2014. This was a fantastic learning experience. I think ElixirConfg was my first real exposure to Elixir / Erlang application design. There were two great talks on this topic:
- Thinking in a Highly Concurrent, Mostly-functional Language by Francesco Cesarini
- Otp In Production: The Nitty-Gritty Details Of Game Servers by Martin Schurrer
I wasn’t ready to apply their teachings at the time but they stuck in my mind. They made me want to learn more about OTP and application design. And when I finally came back to look more deeply into application design I reviewed those talks. They gave me a great place to start and a foundation which allowed me to know what to gp look into in more depth.
The confernece overall showed me what a great community Elixir has and convinced me that my choice to learn Elixir was a good one. I’m looking forward to attending ElixirConf 2015 in October.
Hands on with Performance Measurement
Reading only takes me so far, I learn the most by doing. Also, having a project to work on gives me a context in which to read. So, I started to get more hands on with Elixir.
Diving into an Elixir project was a daunting task as I was just getting started with the language. So I decided to make things easier on myself and tried to work on something in Elixir that could leverage one of my existing skills. In my professional life, I do a lot of performance work so I wrote a series of posts on performance analysis and optimization.
While writing about performance analysis and optimzation in Elixir I ended up developing the bmark tool for Elixir benchmarking. This tool gave me the oppourtunity to write a Hex package and polish my Elixir code for public consumption. And I solidifed the learning process by writing up the process in several more posts here on Learning Elixir.
The learning technique here is to try to learn only one thing a time. So I avoid learning Elixr and web development at the same time. Instead, I focused on learning Elixir and leveraged other skills I’ve already develped. Leaning on my existing skills helps me work through the project more confidently. I don’t have to worry about the problem domain, just how to express the solutions in Elixir.
Reading Code
I spent some time reading Elixir code. I wrote about some of my findings in a short series of posts on patters for using reduce and streams.
I also read through the Elixir Task module in order to better understand how I put it to use.
Reading other people’s code teaches me a lot. I always find something that I haven’t seen before and end up learning how to use it. (Though I need to actually get hands on and apply it before it sticks), Also, it exposes me to different patterns and styles that can help me to improve the readability of my own code.
Dialyzer
I wrote a few posts on Elixir type specs and Dialyzer. At the time I just wanted to get better at using the type system. I’d been reading about other languages with stronger type systems and the safety they provide and I wanted to try that out in Elixir. Now, Elixir’s type system is different than something like Haskell’s but it is still very powerful.
Looking back, I think there is are some general lesons here. The first is that part of learning any new language is to become familiar with the tooling and ecosystem for that language. For Elixir this means learning to effectively use iex, Mix, process observer, dialyzer and others. Tools help us to work more effectively so learning to use the tools available will not only make use better Elixir programers but also make our experience more enjoyable.
A second lesson here is that static analysis, like Dialyzer, can help prevent the devlopment of bad habits. When I’m studying or hacking on Elixir I usually do it alone. Eventually it is posted here on Learning Elixir which is an oppourtunity to get feedback, but it’s not immediate. Pair programming would be another way to get feedback, and tools like Dialyzer are yet another. The main intention of Dialyzer is to prevent bugs but I can also leverage this tool to have it guide me towards better Elixir coding habits.
Next Steps
I listed a few things I want to learn and write about this year in the Learning Elixir year-end review.
The topic I’m finding most difficult now is application design. I’ve touched on this in a few posts already, but the next step needs to be to get more hands on by building a multi-process application with a supervisor tree. Only by getting more hands on can I really experiment and learn about the right way to structure the processes. And of course, I’ll described what I learn here on Learning Elixir.