Almost exactly a year ago, I published a blog post regarding my excitement about Scala. Today, I am writing about an even newer programming language called Elixir.

Motivation Part 1: Scala Seems Impossible

I am not one of those naturally gifted programmers who can pick up new syntax on the fly. I rely on the help of other people and internet searches to get the details about syntax. Anybody who works with Scala would know that this would be a huge problem for an independent learner, such as myself.

This kind of problem has manifested in my life in many ways, including poor performance in math and chemistry classes. I often mix up my bank account and social security numbers. My math tests were always plagued with simple algebraic mistakes, like adding instead of subtracting, or mixing up variable values. In contrast, I excel in conceptual understanding. I believe this is a result of not only natural giftedness (yes, I believe it is biological - let's leave that topic for another day), but also the places where I put focus as a teenager.

As a teenager, I was active in high school debate. This continued through college, for a grand total of 7 years of organized, high intensity, and fast paced competition. The variety of topics which I learned about - and the handful I mastered - gave me a critical tool set which has affected me deeply.

For me, this was the problem with Scala. Coming from PHP, I desperately need something which creates more conceptual engagement. Scala seemed more than promising in this sense. Its orientation around concurrency made me very excited. This provided nostalgia of the sexy work I did before being forced out of my research career, where I worked with graphics cards to perform fascinating calculations in parallel using CUDA.

Furthermore, the functional paradigm offered a new way of looking at programming. This, I felt, was my gateway away from the dreaded "PHP developer" image which I have undoubtedly earned over the last several years. It seemed that by learning Scala, I would not only be able to engage my eager mind, but also overthrow the stigma of the fly-by-night CMS code monkey, who prefers shuffling arrays and cringes at the thought of threading.

With this motivation pushing me forward, I plowed through two Coursera courses taught by none other than Oderski himself. The first introduced functional programming using Scala, and the other was focused on reactive systems using Akka.

A few months later, I was armed with most of the conceptual understanding needed to implement concurrent systems. In fact, I had a lot of it laying around, back from the good old days of CUDA. So, I purchased a few books, chose a framework, and got started trying to build something simple.

My idea was to use the Play! framework with a Scala backend and a Javascript front end. Rather than jump into mapreduce jobs, I figured it would be easier to implement something I knew well - a web site.

I first suspected something was wrong when I realized I'd be writing a lot of Javascript for this project. I don't like Javascript. But, that's another story. The second problem was the admittedly excellent tool Activator.

Activator is a way to download Scala code examples and templates and try them yourself. The community and a handful of companies contribute code and this is a good way to see something in the real world. This is a great idea, but the problem was that every example I looked at was extremely different. I figured choosing an MVC framework like Play! would provide some structure and allow me to leverage examples from different people. The reality was that each project was implemented very differently.

An example will make this clear. In PHP / Drupal land, all websites use MySQL. There is a rigidly defined user object, which is created through a clear registration process, and has a very formal API for adding fields for your use case. A user will always have a userID, an email address, and a password - and Drupal gives that to you. If you want to track a user's first and last name, you add those as fields by implementing a very specific function. This will create the tables in your database and any other code that accesses the user object in the future will be able to see these new fields. Using internet searches, I was easily able to find the function and an example of how to implement it in a blog post.

In contrast, the Play! framework had no formal guidelines for objects like users. You get to choose your own database, and define your own schema. While it is common to use one of the popular FORMs like Slick, not everybody does so.

So here I am, in a new ecosystem, making tough decisions about tool sets and then digging through search results and Activator to puzzle out how to use each one. Everybody was using different combinations of tools, and everybody was using different versions. Therefore, the exact syntax I needed to perform a particular task was usually impossible to find.

The word 'frustrating' does not describe how I felt after months of evenings, spinning my wheels like this. I knew exactly what I needed to do - such as create a schema to store user accounts in PostgreSQL. But, using Slick 2.1-whatever yielded no search results. In the meantime, the examples I did find were filled with seemingly endless syntactic 'tricks' and 'shortcuts' for doing things which I believe should be relatively simple. And, there was no good way to perform internet searches to learn about them.

HAD I BEEN WORKING WITH AN EXPERIENCED SCALA DEVELOPER, THIS WOULD NOT HAVE BEEN A PROBLEM. Somebody who knows this stuff could give me a structured project to work with, and answer questions in seconds regarding syntax. In a matter of weeks, I would have achieved productivity in that project and had the ability to work my way outward. But, this just wasn't possible for me, working alone at home, during evenings.

I almost forgot to mention one minor detail, which is the unavoidable blend of the Scala and Java ecosystems. To be successful in Scala, I also needed to learn Java. This didn't scare me much, but job listings I found consistently reminded me that even after learning Scala, I still had a lot of work to do.

Motivation Part 2: Listen to Those Who Are Smarter Than You

After several months of effort, I had nothing to add to my resume. I had nothing beyond trivial examples which had been expanded outward to perform a handful of simple tasks. Thank god, I never wrote a single line of JavaScript because I never got my backend system to do much.

With each day, I grew wary. Was I actually that code monkey, doomed to shuffle arrays in PHP until I finally burned out and got a job flipping burgers?

I knew this wasn't the whole story. Attending meetups, I started talking to people. Most of them didn't struggle the way I do with the syntax, but they did admit it was unusually difficult to learn. That problem aside, I started asking around about what kind of production systems were using Scala.

To my surprise, there were very few people in my area (Portland OR) who had successfully ran any code on production. Everybody around here is still getting started. So, that helped explain the lack of internet search results. New tools are just harder to learn.

On the other hand, I ended up meeting a few people who told me horror stories of their Scala projects. Teams I truly respected had built sophisticated backend systems using Scala and Akka, and were later forced to rewrite them using other tools. LinkedIn, whose Play! site I really looked up to, published a blog post announcing they were moving all their Play! code off Scala and back onto Java.

One month in spring 2015 I found myself at the PDX Erlang meetup, after I had met a new friend who had presented at the PDX Data meetup. His presentation started to solidify what I was starting to suspect in the back of my mind: Perhaps the grass was not much greener on the Scala side of the fence. In his rambling comparison of Erlang and Scala (which I will not go into here), I started to get the feeling that I would yet again be learning a new tool from the ground up.

Although I wasn't experienced enough to know why exactly, I knew from past experience to listen to the people who were smarter than me. Only later would I be able to articulate the real differences between Erlang/Elixir/BEAM and Java/Scala/JVM (something I will be presenting about next year).

Elixir

Initially, I was more than hesitant to throw away nearly a year of evening study just to gamble on some hot new tool. But, what did I have to lose? My Scala adventure had led only down an eternally forking path of syntactic confusion. My code didn't actually do anything.

My buddy from the aforementioned meetups happens to also run an Elixir meetup. This one is hands on, where I knew I could get help with syntax where I needed it. I had already dove into functional concepts, so that wasn't a hurdle anymore. Erlang sounded great, but the Elixir meetup was my opportunity to get help and socialize here in Portland.

After reading a fascinating paper comparing the JVM and BEAM, I knew that learning Erlang would at least be interesting.

So, just two months ago, I picked up an Elixir book and started working through the examples. Today, I feel confident in my understanding of the primary data structures in Elixir. Furthermore, the syntax is easy for me to read. The code examples I find online almost always make sense to me right away. I can open up source code on GitHub and know which files to open. Often times, I can read the code in those files. Is this supposed to be exciting? Because I am thrilled.

It is extremely refreshing to discover a language oriented around managing processes and facilitating concurrent execution. I feel like it's exactly what I was looking for. And, while I'm eager to dive into Erlang, Elixir has proven to be easy to read - which is a huge bonus for a person like me.