Greetings. I’m Bruce Tate, CTO for I run our team of developers, and still code every day. Over the next few months, I’m going to walk business managers through some of the technology decisions we make, and technologists through how we choose and implement emerging technologies.

In 2015, you’re going to see some noticeable changes to our site. Pieces of our site will get more responsive, and we’ll be introducing some much more interactive concepts. We’ll deliver those new concepts quickly, and we expect them to be able to scale very well, from the beginning. Behind this movement is an exciting language called Elixir. In this article, I’m going to walk you behind the scenes and tell you why we are investing in this language, and what we expect it to do for us.

You might ask yourself “Isn’t one computer language just as good as the next?” That was my attitude for a number of years. You see, computer programmers are best when they are lazy. I hate upgrading my phone. I don’t even change my socks until I have to.

I love Ruby. The language is fast enough for the business problems we throw at it, and it allows us to be extremely adaptable. And, I could give my users better performance just by waiting because computer speeds would double every seven years or so.


A scary paper called The Free Lunch is Over announced an end to this trend. In a nutshell, the way that computers work is changing. Chips used to get faster and more powerful because we found ways to make them smaller. Now, the individual circuits are just a few atoms thick, so we can’t shrink them anymore. Chip makers are responding by stacking up multiple cores on the same chip. To me, the software developer, each chip looks like multiple computers, and the languages I use today does not handle that architecture very well. The cool kids are noticing, and I am noticing the cool kids noticing.

So in 2012, I started going to a new series of conferences, mostly in Europe, that focused on functional programming, a programming style that handles multicore architectures and the problems we see so often on a distributed cloud. If I was going to have to buy my own lunch, it should at least be tasty. These are the things I wanted out of my language:


Any reasonable language for the last half of this decade needs to manage concurrency, and do so as more than an afterthought. The current crop of languages, from Java to C#, from Ruby to Python, either punts on the problem by just doing one thing at a time or puts all of the burden on developers with an approach like threads and locks (Programmers – pick up Paul Butcher’s excellent book called Seven Concurrency Models in Seven Weeks for more insight.) We need languages that handle concurrency in a fundamentally different way.


The Perl language allows you to write some of the most densely compacted programs in the industry. At it’s peak, Perl had contests called “Golf” for the programmer who could express a given problem with the shortest program possible. The problem is that we write a program once, but read it thousands of times.

So we don’t want a write-only language. It has to be easy to write, and easy to read, with more weight given to the readability.


We need to be able to test quickly, have an interactive console for exploration and handling emergencies, create custom repeatable tasks for deployment or development activities, and the like. We also need to be able to contribute to the language community, and consume the contributions of others.


Programming is about expressing concepts. Expressing these concepts in the most native language possible makes programs easier to read and write. Put another way, if programming is about expressing idioms and my language can translate larger idioms into smaller programs than yours, I am going to win because I am building with larger blocks than you.


Good languages have mechanisms for dealing with failure. Great languages insulate the typical programmer from ever having to deal with failure.

That’s a pretty daunting list. But I’m lazy, and I really need a language that will let me slack off in all of the right ways.


Eventually, I found three alternatives. They were:


We could keep coding in Ruby and just pay more for hardware. Ruby satisfies 2, 3, and 4. Ruby is weak at 1 and 5, and on multicore, will become hopeless. For a while, we decided to stay on Ruby because we didn’t like the other alternatives enough.


This language solved 1 and 5, and better than anyone else ever has. Erlang runs a significant chunk of the world’s messaging traffic. It’s the language behind that obscene acquisition by Facebook, WhatsApp. But from a syntax
perspective, the language is a wreck. The metaprogramming is also weak.


This language solved 1, 3, and 4. It had a macro system that allows perhaps the best metaprogramming facilities of any language we were considering. It was horrible at 2 and middle-of-the-road at 5. If we were a Java shop, it would be all over. Instead, we decided to keep looking.

What we really wanted was a twisted love child with DNA from all of these three alternatives.


In 2012, I heard about the work of José Valim. He was one of the most prolific developers in the Ruby space. He’d actually been reading one of my books, Seven Languages in Seven Weeks (or on Amazon), and it turns out we were thinking in many of the same directions. I sat in a talk about his new language Elixir, and was tremendously impressed.

I started going to Erlang conferences and others to speak about Elixir, and became more and more convinced that it was the language for us. Elixir combined the natural syntax of Ruby with the Erlang virtual machine and libraries for concurrency and failover and the macro system from Clojure.

In October, we started our Elixir development. We’re working on some real-time features for our communities and surveys that will allow a much more interactive style of market research. So far, we’ve been incredibly productive. We’ll be able to claim 100% code coverage, and a highly interactive and concurrent application that will let us scale just about indefinitely.


As a customer of, you’ll notice that our features built with Elixir are much faster and more reliable. They are also more interactive, because the language lets us model a much more concurrent world. Our costs will stay low, so yours will too.

As a technologist, you will notice that we’re investing in the language. We’re committing core code to the language and creating a groundbreaking open-source testing framework – Shouldi – to support the ecosystem.

As a developer, you should care because with Elixir, you don’t have to give up scalability for fun.

It’s going to be an exiting year, and we plan to tell you about it as we go through this remarkable transition.