As CTO at TSC, this is one of the questions I am asked most often: Why choose niche technologies such as Elixir and Phoenix, rather than using something more mainstream like Java, Ruby, or Python? The answer encompasses both the type of people I want on my team and the sheer advantages of the technology for TSC’s specific use cases.

I have originally posted this article on TSC’s website, but I thought it would be relevant for OSOMac’s readers as well.

I want to work with people who love technology and development

Before getting into the technical reasons which make Elixir a great choice, I want to address the very first concern everybody raises. Where do we find people with the right technical experience and skill when most developers haven’t even heard of this language? Indirectly, this is the first test in an interview: if somebody has not heard of some new technology, it might mean that development is just a job for them, and I do not want them on my team. Business is going well, so we are happy to invest the time to allow a new hire to learn something new, as long as we get passion and commitment in exchange. At TSC, we want things done correctly, and would rather have a deadline missed than accumulate technical debt.

I am proud to say that we have world-class Elixir developers on our team, and none of them had previously used the language in a professional context before joining our team. Now they interact with the creators of the language and contribute to Open Source projects. Not only that, but they have fun and enjoy what they are doing.

We plan to start hosting Elixir meetups at TSC soon, with the goal of helping to make this technology more mainstream.

Functional Programming is the way to go

Even though this programming paradigm is not taught enough in Computer Science schools—which seem to be unable to move on from Object-Oriented Languages such as Java—the added robustness and scalability are too important to be disregarded. What seduced me years ago was the concept of immutability: it is so simple, yet it solves most of the issues related to concurrency and multi-threaded applications. Welcome to a world where Mutexes, Semaphores, and blocking code are things of the past.

The functional style also leads to simpler and more reusable code. This means not ending up with the thousands–of–lines–long procedures of Imperative languages, or unreadable class structures typical of Object-Oriented languages (which technically are sub-types of Imperative Programming).

Elixir has rock-solid foundations

First, Elixir was created by the same people who created Ruby on Rails. It maintains a lot of the cool concepts of Ruby while pushing towards a purely functional style. Secondly, Elixir is based on Erlang, which is arguably the most scalable and robust stack existing today. Erlang does not need introductions; it has been used in mission-critical applications for decades and shines for its massive scalability and robustness. Threads crash and hang, but this is part of the design of Erlang, which makes small bugs and software instabilities something that can be handled at runtime.

Elixir repaints Erlang with a modern syntactical structure, greatly improving readability and productivity. On top of Elixir, the Phoenix Framework incarnates the best concepts of modern frameworks, taking many ideas from Rails, without the dogmatism into which Rails seems to have fallen lately.

Last but not least, the tools available for Elixir & Phoenix are impressive for such young technologies. This is incredibly helpful for increased productivity and is still very lean.

Conclusion

In May 2017 we started a complete rewrite of TSC’s main product, Atium, which was previously written in PHP. Before year end, we had our first clients live on the new stack. Within the first half of 2018, all of our existing clients were migrated to the new product. We have not had any unplanned downtime since the system went live. Atium is a very complex system: the short time it took to our small team to build the platform, and the resilience of the end-product are proof of the dependability of the technology stack we have chosen. Stay tuned for future posts on our architecture and security design.