It’s been a long time coming, my dear
It’s been a long time coming, but now it’s here
And now it’s hereBruce Springsteen, “Long Time Comin'”
I think I have finally committed to seriously studying the Phoenix framework and Elixir, which is the language it written in. This is a long time coming.
The Elixir Pitch — Hearing it the First Time
Probably five or six years ago, I first heard of this hot new thing that a lot of Ruby on Rails people were migrating towards. For some reason it didn’t ring my bell. Eventually, I saw this Elixir documentary and I developed enough interest to start looking at it.
Overheard in the theater Documentary-style promotional videos are now perhaps overused, but sometimes the editorial love is deserved, which I think is the case here.
Still, I looked but I didn’t buy. And years passed. But now I feel like I’m ready to dive in. What has changed?
Buying in is a big deal, because the only way to know a technology will be useful and productive, is to invest a great deal of time and attention learning how to use it and becoming familiar with the ecosystem and community surrounding it.
Buying In (Buyer Beware!)
A decade ago, I committed to learning Ruby on Rails so that I could take on a startup project for a friend of a friend. I had always had a toe in technology, having built my first website 15 years earlier, when I was 16 or 17 years old, and since then had used various content management systems to engage in web publishing. I was convinced I could reach the new threshold of “building software” by a very clever interactive short course called “Rails for Zombies”. To get a sense of this strength of the sales pitch, check out a promotional video the creators made.
A plethora of support and positive energy
There was also the famous build-a-content-management-system-in-15-minutes video by the creator of Rails. And the Rails for Zombies folks (Code School) had other interactive training ready and coming down the pipe which suggested to me that I could keep leveling up in increments (while being entertained). Of course, I ran out and bought the “Hartl tutorial” printed book (plus 18 hours of video lessons on DVD). And let’s not forget RailsCasts, which may have wiped out its maintainer due to its popularity.
There was even a bizarre why's (poignant) guide to ruby which I had a local printer make me a physical copy. The printer said he didn't know if it was a comic book or a technical book.
For me personally, the biggest attraction of the Rails community was fun-loving and friendly personality that seemed to emerge from the language design itself. Ruby’s creator Matz said that he created Ruby to make programmers happy. Rubyists took on the motto of “MINASWAN” — “Matz is nice and so we are nice.”
Even with a great community, technology moves on, and experience accrues (the bad and the good).
More Experience -> More Options -> Choosing carefully matters
Having gone through many battles with Rails, as well as delving into surrounding technologies, I was of course curious about better alternatives. There were many alternatives, but they seemed to fit into one of two categories: 1) Languages with frameworks that were Rails-like (but not much better performance) or 2) languages (like Golang or Haskell) with better performance, but without a focal web development framework. I personally have spent a lot of time studying Haskell, and I am kind of in love with it, but I have recognized it is probably not practical for the projects I’m trying to actually deliver to the world.
It is easy to get into a technical rabbit hole and lose track of reality and the need to focus on the shortest path delivering value. It is okay to add some distance to the solution if overall productivity is increased. In productivity I’m also including the cost of upgrading and maintaining a technical solution. One difficulty with Rails is that Ruby’s flexibility and dynamic nature has encouraged code that too often resembles impenetrable whimsical magic and requires tinkering/digging to understand its behavior and additional controls to prevent the magic from being dangerous.
Being wary is advised, but not so much that caution destroys curiosity. And it feels good to get excited about learning something that is fun to use and could make life and work better for everybody (or at least myself).
Buying In (literally)
Functional and Fun
In his introduction to Programming Elixir, Dave Thomas says that he also didn’t bite when he first heard about Elixir. I think one factor is that everyone is waiting to see what is going to stick — what others are going to invest in. From my point of view, the fact that I could get a book by Dave Thomas, who was a great early supporter of Ruby, helped convince me that this was something worth learning, even if it was just to get his take on why it reminded him of Ruby and why it was worth learning in addition to Ruby.
Dave Thomas writes that his motivation was he wanted a good way to teach people functional programming (without being too academic). Functional programming has come into focus not merely as an alternative style of organizing computing concepts but by the need for predictability and control of computing systems. It is actually a matter of cybersecurity to know what state a program is in given particular inputs. Pure functional programs always perform the same way given the same input. Each functional component by itself (the individual function) is understandable and the compositions of such functions concatenate this predictability.
I learned functional programming in Haskell, which I think is probably a good discipline, since Haskell is thought to be the most pure functional language in use. But Elixir isn’t so strict and demanding. Elixir feels like Ruby in its syntax. Elixir might even be “fun”. Elixir is also kind of Lisp-y which allows metaprogramming similar to Clojure.
Not so academic Category theory is often held up as co-requisite of understanding Haskell and pure functional programming. Dave Thomas throws category theory talk under the bus, "Tell me about monads just one more time." The student of Haskell inside me laughed. You can understand why I laughed if you just watch 12 hours of Bartosz explaining category theory. Bartosz is a delight, but category theory is hard.
“Ruby on Rails but Fast”
Elixir also has the Phoenix framework . While Phoenix is organized very similarly to Rails (in names and conventions), it is built on Elixir which compiles onto the Erlang Virtual Machine (BEAM) which was engineered to run fault-tolerant, distributed telephone systems. The Open Telecom Platform (OTP) within Erlang provides an underlying toolkit that makes Elixir an ideal candidate for building microservices.
Understanding the power of this underlying system seems to be a kind of secret sauce that isn’t easily reproducible on another software stack. Check out this article on the evolution of OTP, Erlang, and Elixir.
The end of the beginning…
I’m just at the beginning of my Elixir journey, I’m only 10 chapters in, about a third of the way through each of the Pragmatic books. Now, I have to keep on digging in and finding ways to keep having fun while doing so. It is time to open all the doors and push all the buttons.
I am equally excited about the possibility of getting involved in the Elixir community and making new friends.