I spent the last couple of months working from home (thanks to the lockdown) and it sure felt like an opportunity for a fresh jump, like learning a new technology which is both promising and mature enough to use in production: Elixir .
I’ve experimented with Erlang in the past, but I can’t say that was amusing (I recall I had to learn Erlang to support a legacy product in a previous company). From this 1st encounter with the Erlang ecosystem I keep the positives, which is the «Programming Erlang» book by Joe Armstrong and the amazing discovery that Erlang basically powers the Internet as we know it.
I also happened to work for a few months in a software product that was based in Akka, which is merely a JVM implementation of the Erlang actor model, but this too didn’t attract my attention. Somewhere after 2016 I discovered this cool new kid on the block (Elixir) but didn’t devote much time into it at that time, as it was being advertised simply as a replacement for Rails.
So to make things short, it happened that we did a 2-week «innovation sprint» in my current company, We were to write a ‘walking skeleton’ of our next version product suite, and for the part I picked up, I set up a Phoenix based REST API in literally no time (thanks to the built-in generators) and managed to progress from «proof-of-concept» to «hey this actually works with real data» in spectacularly short time. Then as I dived more and more into the language, more miraculous stuff began to happen:
I started adding features at an astonishing rate. (Ad-hoc drilldowns? auditing? live updates? performance monitoring dashboards?) As I added more and more functionality, I realized I wanted to test with more diverse set of input data that no canned-response API would be able to provide. For this purpose:
I took interest in rewriting an abandoned sibling project (that was transforming data for feeding the PoC REST API from XML). This Spring Boot project was initially written in some 2400 lines of Java (but was still incomplete). After a couple of days of effort I ended up with… 500 lines of XSLT (yes, good-old XML stylesheets!) and 350 lines of Elixir. The fun part is that the Elixir implementation includes testing and satisfies all MVP-scope requirements.
In doing so I accidentally discovered a real-world analogy of the Prime Directive in exposing this «alien technology» to the rest of the development team, for they simply wouldn’t accept my statements as valid («what do you mean, it’s ready? what do you mean you added auditing?«), and would even refuse to look at the code. To this day I’ve yet to find a soul to review my merge requests, so I rely on automated tools like Dialyxir to run code checks automatically.
I’ve now stepped into dangerous territory of trying to convince coworkers (better yet, friends that I know for years!) that I’m not threatening their job security (yes, for Christ sake!).
- «Who’s going to support any Elixir code? What if you get hit by a bus? (which reads: «please stop what you’re doing, you’re harming the team and the company«)
- «If some of us take the plunge and learn Elixir, how relevant will we be with the job market and its then-current trends in say 5 years?«
In short, both valid questions, but then both just as invalid as counter-arguments to trying out a new language. Can you not learn a second foreign language? Do all students studying Spanish need to wipe their memory clean of their German?
Well, maybe my coworkers are right, maybe the walking skeleton proof-of-concept was the Kobayashi Maru. Unlike what Spock thinks, I didn’t cheat out on this one, but I think maybe I did something more like what Zefram Cochrane did , which led the Vulcans to come pay us a visit (and upload some cool new Elixir artifacts to hex.pm as welcome gifts 🙂 )
One thought on “Of Elixir, Phoenix, and analogies to the Prime Directive”