28 Days - Bringing Elixir to Others - New Language vs. New Paradigm

I’ll be giving a talk next week about taking Elixir into production. While there are technical challenges to doing so, I must also consider the human-based challenges that will be faced. For example, most team members will be learning a new language when they are introduced to Elixir. If they have been doing object-oriented coding, will a functional coding paradigm get them stuck? Will OTP and the paradigm of a process based application cause confusion?

I won’t necessarily present answers to some of these questions today, but rather bring up questions that I’ve heard and alternative ways of thinking about the answers.

Functional Programming and Elixir Itself

Before all of the fun and excitement of making a real Elixir application comes the challenge of learning the Elixir language. Most people that ask me about learning Elixir focus on what types of courses they can pay for online to get into the language. While I’m sure that some people are going to benefit from these courses enormously, it’s never the first place I’d send someone. Instead, I recommend the Elixir Getting Started Guide. This guide is put together by the official Elixir team and covers an introduction to the language itself.

As other members of the organization dive into the concepts of Elixir, questions will be raised about what functional programming is, what does immutability mean, and what is “all of this” in practice? Even further questioning might ask “what makes the functional paradigm good?” Other team members will rely on the Elixir champion to answer these questions, so be prepared for them to pop up once people start learning. I read something in a reddit comment today that I really liked on this topic: the value of the data doesn’t change in Elixir, but rather the variables point to new pieces of data. I thought that was a very straight-forward way of looking at the functional programming model that Elixir brings.

I prep anyone that is going through the getting started guide that it will take probably 2-4 times to really understand Elixir to the point of being comfortable when reading other people’s code. Having a real world project to read and play around with can lower this learning curve.

OTP

OTP is a cornerstone of writing Elixir applications. There’s lot of things about the topic already, but I had an interesting observation the other day about OTP and how it relates to bringing Elixir to the rest of an organization:

The majority of business applications could be built with all OTP hidden away by libraries, to the point of developers not needing to know the details of OTP.

While I think that using OTP can help bring about advantages in an application, especially in a distributed environment, it is not really necessary. For example, a developer could start a new application today and serve the HTTP layer with Phoenix. They could then spin up a queue system like ExQ in order to process background jobs. Finally, they can connect websockets for read/write access to the API. All of this can happen without ever typing GenServer in code and create an application which satisfies the business.

This isn’t necessarily best practice, but I believe that it’s okay to sometimes put aside best practice in order to achieve an initial velocity. Once the team is rolling, the OTP concepts will come out of the woodwork and start to make sense, hopefully faster than they would in isolation.

Regardless of how you approach bringing Elixir to the people on your team, realize that you must be a champion for the education and empowerment of the team. Look for interesting ways to answer questions that people have and remove the roadblocks that pop-up as quick as you can.

Thanks for reading the third post in my 28 days of Elixir. Keep up through the month of February to see if I can stand subjecting myself to 28 days of straight writing.